📖 Features & How-To

🗺️ XML Sitemap Guide

Content Pruning

Open Graph Tags

🤖 Robots.txt: Best Practices and Site Audit Warnings

⚙️ JavaScript SEO & Website Studio Crawlability

🕷️ Crawl Monitoring

HTTP Status Codes

🕷️ What Are Crawl Errors in SEO and How to Fix Them?

⚡📄 Google Page Experience Update

Understanding JavaScript Rendering and Search Atlas Site Auditor

Hreflang Attribute

Global websites often serve audiences in multiple languages or regions. Hreflang tags help Google show searchers the right localized version of your web pages. This guide explains what hreflang tags are, how they work, and how to implement them correctly. 🌍 Hreflang Basics For global brands, creating a multilingual site is a powerful strategy. Hreflang tags communicate to web crawlers that multiple versions of a page exist — each tailored to a specific language or region. Note: Hreflang is supported by Google and Yandex, but not by Bing or other major search engines. Bing instead relies on the content-language meta tag, which is worth implementing alongside hreflang if you have significant non-Google traffic. 🧩 What Are Hreflang Tags? Hreflang tags are snippets of HTML code that tell search engines which page to serve to which users. Example: <link rel="alternate" href="https://example.com/en-us" hreflang="en-us" /> This tells Google to show the U.S. English version. For Hong Kong English: <link rel="alternate" href="https://example.com/en-hk" hreflang="en-hk" /> This helps Google determine the most appropriate version to show users based on their location and browser language settings, though the final decision remains with Google's algorithm — hreflang is a strong hint, not a guaranteed override. 🔤 Language and Region Code Standards Hreflang values must follow recognized standards, or Google will ignore them: - Language code (required): ISO 639-1 — e.g., en, es, fr. - Region code (optional): ISO 3166-1 Alpha 2 — e.g., US, HK, GB. You can use the language code alone (e.g., hreflang="en") when you don't need to target a specific country. Combine the two with a hyphen — language-REGION — to target a region-specific audience (e.g., en-US or en-HK). ⚙️ How Hreflang Works At a conceptual level, hreflang helps Google understand the relationship between localized versions of a page so it can serve the most appropriate one to each searcher. Crawling, indexing, and ranking are separate processes that don't necessarily occur in a strict sequence for every request — the points below describe the general roles each step plays rather than a fixed linear flow: - Google crawls and evaluates whether a URL is eligible to rank. - Hreflang annotations are read to identify alternate language and regional variants. - When a searcher's region or language matches a variant, Google may surface that version in results. If no specific match is found, Google falls back to the page marked "x-default." 🌐 Using the x-default Tag The x-default value tells Google which page to serve when none of your other hreflang variants match the user's language or region. Example: <link rel="alternate" href="https://example.com/" hreflang="x-default" /> A good x-default page is one of the following: - A language/region selector page where users can pick their preferred version. - A neutral global landing page with no specific localization. - The most universally applicable version of the page (often English). Always include an x-default entry in your hreflang cluster — it removes ambiguity for unmatched users and is considered a best practice by Google. ❓ Do You Need Hreflang Tags? If your site has multilingual or region-specific content, yes — hreflang tags are essential. Without them, users may land on the wrong language version and quickly exit your site, increasing bounce rates. 📈 SEO Benefits of Hreflang Tags - Improved rankings in specific regions/languages - Avoids duplicate content penalties - Lower bounce rates - Better user experience for international visitors - Higher conversions and leads 🔗 How Hreflang Differs from Rel Canonical Rel canonical tells Google which single version of a page to index. Hreflang, on the other hand, tells Google that all versions should be indexed — each for a different audience. ✅ Each localized page needs its own self-referencing canonical. If canonicals point to a default or different URL, Google may ignore your hreflang tags. 🔁 Reciprocal (Bidirectional) Linking Requirement Hreflang annotations must be bidirectional. If Page A links to Page B with an hreflang tag, Page B must link back to Page A with a matching hreflang tag. If the link isn't reciprocated, Google may ignore the annotation entirely. Example — these two pages must each reference the other (and themselves): <!-- On https://example.com/en-us --> <link rel="alternate" href="https://example.com/en-us" hreflang="en-us" /> <link rel="alternate" href="https://example.com/en-hk" hreflang="en-hk" /> <!-- On https://example.com/en-hk --> <link rel="alternate" href="https://example.com/en-us" hreflang="en-us" /> <link rel="alternate" href="https://example.com/en-hk" hreflang="en-hk" /> Missing reciprocal tags is one of the most common — and most damaging — hreflang implementation errors. 🛠️ How to Implement Hreflang Tags Once your language versions are live, you can add hreflang tags using one of three methods: HTML <head> tags, HTTP headers, or XML sitemaps. Choose the method that best fits your site type and scale. Option 1: Adding Hreflang to Individual Pages (HTML <head>) Best for small to medium HTML sites. Step 1: Write hreflang tags with accurate language and region codes. Step 2: Specify a default version for cases where language/region is unknown. Step 3: Add all hreflang links to the <head> section of the default URL. Step 4: Add reciprocal hreflang links to every language variation. Step 5: Ensure rel canonicals are self-referencing. Example markup placed inside <head>: <link rel="alternate" href="https://example.com/en-us" hreflang="en-us" /> <link rel="alternate" href="https://example.com/en-hk" hreflang="en-hk" /> <link rel="alternate" href="https://example.com/" hreflang="x-default" /> Option 2: Adding Hreflang via HTTP Headers Use HTTP headers for non-HTML files such as PDFs, where you can't add tags to a <head> section. Example HTTP response header: Link: <https://example.com/file-en-us.pdf>; rel="alternate"; hreflang="en-us", <https://example.com/file-en-hk.pdf>; rel="alternate"; hreflang="en-hk", <https://example.com/file.pdf>; rel="alternate"; hreflang="x-default" Be cautious — adding many hreflang entries via HTTP headers can add server overhead, so use this method only when needed. Option 3: Adding Hreflang via XML Sitemap XML sitemaps are often the preferred method for large sites because they centralize hreflang management and keep page-level HTML lean. Step 1: Use the xhtml:link attribute below each default URL. Step 2: Add every alternative URL to the sitemap as well, each with its own complete set of xhtml:link references. Example sitemap entry: <url> <loc>https://example.com/en-us</loc> <xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/en-us" /> <xhtml:link rel="alternate" hreflang="en-hk" href="https://example.com/en-hk" /> <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/" /> </url> This method reduces page load time by keeping hreflang data out of HTML headers and scales well for sites with many localized URLs. 🚨 Common Hreflang Mistakes - ❌ Invalid language or region codes - ❌ Incorrect rel canonical usage - ❌ Missing reciprocal hreflang links - ❌ Excessive server overhead from HTTP header hreflangs - ❌ Lack of professional review or QA Consulting SEO professionals ensures tags are implemented correctly and efficiently. 🔍 Validating and Testing Your Hreflang Tags After implementation, always verify that your hreflang tags are working as expected. Use one or more of the following: - Google Search Console: The International Targeting report flags missing return tags and invalid language/region codes across your verified properties. - Third-party hreflang testers: Tools such as Merkle's hreflang Tags Testing Tool, Sistrix Hreflang Validator, or Ahrefs/Screaming Frog's hreflang reports can audit individual URLs or entire sites. - Manual spot checks: View the source of each localized URL to confirm that hreflang and self-referencing canonicals are present, reciprocated, and use correct ISO codes. Run validation after every major site change — new languages, URL migrations, or template updates can all silently break hreflang clusters. 🌐 The Value of Hreflang and International SEO International SEO requires effort and precision — but the reward is global visibility and higher engagement. By offering content in users' native languages, you improve user experience and signal quality to Google, which rewards your site in global search results. ✅ Closing Note Implementing hreflang tags correctly ensures your website serves the right content to the right audience, increasing both satisfaction and conversions. If you're expanding internationally, hreflang is one of the most powerful SEO tools you can use.

🧩 Schema Markup

Some webmasters feel intimidated when working on the backend of their websites. However, the metadata you include on a page, and how it’s formatted, can have a meaningful impact on SEO performance. One of the most powerful types of SEO-friendly metadata is schema.org markup. Schema markup is a form of structured data that helps search engines better understand your web pages. It also improves how your pages appear in search results, increasing both visibility and click-through rates. The good news is that anyone can add schema markup, you don’t need to be a developer to get started. This guide explains what schema markup is, why it matters for SEO, and how to create and manage it effectively. 🔍 What Is Schema Markup? In simple terms, schema markup is a semantic vocabulary added to your website’s code to help search engines generate more informative and relevant search results. - On the backend, schema.org markup is implemented as structured data within your HTML. - On the frontend, that markup can generate rich results in Google, enhanced search listings that show more context than a standard snippet. A standard search result usually includes: - Page title - URL - Meta description A rich result, enabled by schema markup, can additionally show: - Business hours - Star ratings - Event details - Product or recipe information Schema markup is what allows search engines to surface this additional data. To standardize how structured data is interpreted, major search engines, including Google, Yahoo!, Bing, and Yandex, collaborated to create schema.org, a shared vocabulary for describing businesses, products, reviews, jobs, and more. 📈 SEO Benefits of Schema.org Markup Despite its advantages, schema markup is still underused. Implementing it can give your site a competitive edge without changing your on-page content. 🧠 Clearer Meaning for Search Engines Schema acts as a translator, helping search engines understand what your data represents, not just the words on the page. ✨ Enhanced Search Results Rich results stand out visually and provide users with information aligned to search intent—helping them decide faster. 🖱️ Higher Click-Through Rates (CTR) More informative listings lead to better engagement. Schema helps each page communicate its purpose clearly in the SERPs. 📍 Stronger Local SEO (Especially on Mobile) On mobile devices, rich results and carousels take up more screen space. For local businesses, this can significantly increase visibility and brand presence. 🔐 A Competitive Advantage Only a minority of websites actively use schema markup, making it one of the easiest ways to stand out in crowded search results. 🧠 Common Schema Formats 🎨 Creative Works Used for media such as books, movies, games, and music, highlighting attributes like ratings, genres, and availability. 🧬 RDFa A framework embedded directly into HTML attributes to describe relationships and metadata. 🧩 Microdata Uses attributes such as itemscope, itemtype, and itemprop to define structured data elements. ⚙️ JSON-LD (Recommended) The most widely recommended format. JSON-LD is easy to implement, flexible, and can be added to the <head> or body of a page. 🧭 How to Choose the Right Schema Markup Selecting the right schema starts with understanding the purpose of each page and how it supports your broader SEO goals. A practical approach includes: 1. Identifying your core business information 2. Mapping pages to the appropriate schema.org vocabularies 3. Determining whether content is recurring or one-off 4. Connecting structured data into a coherent knowledge graph When search engines clearly understand your site’s context, relevance and visibility typically improve. 🛠️ How to Use a Schema Markup Generator Schema generators simplify implementation by producing ready-to-use JSON-LD code—no manual coding required. 📍 Where to Find the Schema Creator in Search Atlas To access the Schema Markup Generator, follow this exact path inside the platform: ➡️ Header apps-grid icon (More Features) ➡️ Schema Creator 💡 The apps-grid icon in the header opens the More Features menu. 🧩 Typical Schema Creation Workflow Once inside the Schema Creator, the process is straightforward: 1. Select the appropriate schema type (e.g., Article, Local Business, FAQ Page, Product, Organization) 2. Fill out the structured fields (headline, URL, images, author, publisher, dates, etc.) 3. Review the auto-generated JSON-LD preview on the right panel 4. Click Copy Markup 5. Paste the JSON-LD code into the <head> section of your webpage ✅ Validate Your Schema Markup After publishing, validate your structured data using: - Google Rich Results Test - SEMrush Site Audit - Google Content Markup Guide - Schema.org official documentation ✨ Why This Matters Using the Schema Creator ensures: - Clean, error-free JSON-LD - Faster implementation without developers - Better eligibility for rich results - Consistent structured data aligned with Google standards This tool removes friction from technical SEO and makes structured data accessible to every team. 🚀 Schema Management & Suggestions in Search Atlas Search Atlas includes built-in tools to help users review, update, and improve schema markup without working directly in code. To access schema recommendations and management inside Search Atlas, follow this path: From the Left Sidebar: ➡️ OTTO SEO ➡️ All Sites ➡️ Select your project ➡️ Overview ➡️ Onpage Optimizations (OTTO Grader) ➡️ Click Schema Markup This opens the Schema Markup recommendations view, where you can review existing schema, see suggestions, fix missing values, and regenerate schema when needed. 👁️ Organization-Level Schema Preview & Editing At the top of the Schema Markup section, you’ll see the Organization-level schema for your project. From this area, you can: - Click Preview to see how the Organization schema will appear - Edit schema fields directly inline - Update values without navigating to the Knowledge Graph - Save changes when ready 💡 Note: The Knowledge Graph is still available for advanced edits, but previewing and updating Organization-level schema no longer requires leaving this view. 🧠 Schema Suggestions for Individual Pages Below the Organization schema, you’ll find a list of pages with schema recommendations. For each page: - The page URL is listed - A schema suggestion is available when applicable To review a suggestion: 1. Click Reveal Schema 2. Review the suggested structured data 3. Choose one of the following actions: - Edit the fields manually - Click Regenerate Schema to generate a fresh version based on the latest page content This is especially useful after updating page copy or metadata. ⚠️ Fix Indicators for Missing Required Fields For Auto Projects: - Schema recommendations appear automatically - Users can click Generate or Regenerate to apply schema - No manual setup is required This keeps schema aligned with content updates over time. 🚫 Current Limitation At this time: - Users cannot manually create brand-new schema types - Schema management is limited to: - Organization-level schema - System-generated schema recommendations - Editing, fixing, or regenerating existing schema Manual schema creation will be added in a future update. 📦 Auto Projects & One-Click Generation For auto-generated projects: - Schema suggestions appear automatically - Values can be generated with a single click - No manual setup is required This makes schema optimization easier to maintain over time. Schema markup remains one of the most underutilized yet impactful SEO tools available. With previews, suggestions, and validation built directly into Search Atlas, structured data no longer requires technical expertise to manage. By applying schema consistently, you can improve search visibility, click-through rates, and long-term SEO performance—making structured data a foundational part of your optimization strategy.

📘 How to Allow Search Atlas's User Agent in Cloudflare

If you want to run a site audit and monitor your site health using Search Atlas, sometimes our site crawlers get blocked by CDNs. Content Delivery Networks (CDNs) are a group of servers that help deliver website content faster. If your website relies on a CDN to increase the performance of your website, then it's possible the CDN's firewall will block our crawler from accessing your site. Resolving this issue requires allowlisting the Search Atlas crawler's user agent so it can reach your site, since our crawler doesn't use static IP addresses. This post will explain how to do so on Cloudflare, as it is the most popular CDN provider for webmasters. If you are using another CDN, the process is similar, and can still be done by following the steps outlined below. Search Atlas crawler user agent: Search Atlas Bot (https://www.searchatlas.com/) — use this exact string when creating allowlist rules in Cloudflare, WordFence, or any other firewall or security plugin. 💡 Using OTTO? You can connect your Cloudflare account directly via API token in OTTO Settings → Integrations. This is the preferred method for handling Cloudflare-related access and may resolve crawler access issues without requiring manual firewall changes. ⚙️ Step-by-Step Instructions 🧱 How to Allow Search Atlas's User Agent in Cloudflare The recommended approach is to create a WAF Custom Rule (or Firewall Bypass Rule) that specifically allows the Search Atlas user agent, rather than disabling bot protection site-wide. Follow these steps: Step 1: Log in to your Cloudflare account and select your domain. Step 2: Go to Security → WAF → Custom rules. Step 3: Click Create rule and give it a name (e.g., "Allow Search Atlas"). Step 4: Set the field to User Agent, operator to contains, and value to Search Atlas Bot. Step 5: Set the action to Skip and select the security features to bypass (such as Bot Fight Mode, Super Bot Fight Mode, and Managed Rules). Step 6: Click Deploy to save the rule. After performing the above steps, Search Atlas will have access to your website for monitoring while your bot protection remains active for all other traffic. ⚠️ If you must disable Bot Fight Mode entirely (because a Custom Rule isn't available on your plan), be aware this removes bot protection from your entire site. We recommend re-enabling it as soon as the Search Atlas crawl completes. 👉 For more details, see Cloudflare's WAF Custom Rules documentation. 🔐 How to Allow Search Atlas's User Agent in WordFence (WordPress) Rather than disabling the entire firewall, allowlist the Search Atlas crawler so other protections stay in place. Step 1: On the WordPress menu, go to WordFence → Firewall → Allowlisted URLs (or Allowlisted Services). Step 2: Add a new allowlist entry for the user agent Search Atlas Bot (https://www.searchatlas.com/). Step 3: Click Save Changes. 🧩 How to Allow Search Atlas's User Agent in Stop Bad Bots (WordPress) Step 1: On the WordPress menu, go to Block Bad Bots → Settings. Step 2: Go to the Settings tab. Step 3: Disable the Block All Bots option, or add our user agent Search Atlas Bot (https://www.searchatlas.com/) to the allowed list. 🔐 How to Allow Search Atlas's User Agent in Blackhole for Bad Bots (WordPress) Step 1: On the WordPress menu, go to Blackhole → Settings. Step 2: In the Whitelist User Agents section, add the user agent Search Atlas Bot (https://www.searchatlas.com/). Step 3: Save changes. 🛡️ How to Allow Search Atlas's User Agent in Shield Security (WordPress) Step 1: On the WordPress menu, go to Shield Security → IP Rules. Step 2: Use the gear icon for additional options and select Create New User Agent Rule. Step 3: Add the Search Atlas Bot (https://www.searchatlas.com) user agent to the bypass/whitelist list. Step 4: Click Create New Rule. 🛠️ Troubleshooting: Cloudflare Not Detected in OTTO My Cloudflare token is connected in OTTO but Cloudflare still shows as not installed — what should I do? If you have connected your Cloudflare API token in OTTO settings and validated it, but OTTO still shows Cloudflare as not detected or inactive, this is a known issue our team has investigated. Please contact Support with your domain and token details so we can review the connection on our end and resolve it for you. ✅ Closing Note Allowing the Search Atlas User Agent ensures your site audits and monitoring run smoothly without interruption from security plugins or CDNs.

Broken Links: Causes, Impact, and Fixes

Broken links are hyperlinks that lead to non-existent pages, often resulting in error codes like 404. They occur due to deleted content, URL changes, typos, server errors, or redirect issues. Broken links harm SEO, frustrate users, and reduce brand credibility. This guide explains what broken links are, why they happen, their impact, and how to detect, fix, and prevent them. 🔎 What Are Broken Links? Broken or dead links are hyperlinks that no longer work, leading users to error pages. Types of broken links include: - Broken internal links – lead to non-existent pages on your own site. - Broken external links – lead to missing content on other sites. Broken backlinks – exist on other sites but point to missing pages on yours. ⚠️ What Causes Broken Links? There are several common causes: 1. Deleted or moved content – Pages removed during redesigns or updates. 2. Changes in URL structure – Renaming folders or categories without updating links. 3. Misspelled URLs – Typos when inserting links. 4. External content removal – Linked resources deleted or updated by other sites. 5. Server or protocol issues – Downtime, HTTPS/HTTP mismatches, or blocked resources. 6. Redirect chains or loops – Circular redirects make pages inaccessible rather than technically missing; fixing them requires editing redirect rules, not restoring content. 7. AI-generated or automated content restructuring – Tools that automatically move, merge, or reorganize page content can break previously valid URLs if the project is not republished afterward. Soft 404 errors – Pages returning “not found” messages without proper error codes. Note on CMS/site-builder 404s: Some CMS or site-builder platforms (including Search Atlas Website Builder) can generate pages that return a 404 even when a button or navigation link points to them. This typically happens when the underlying page is empty or unpublished. Verify that pages are fully published and contain content, not just linked in navigation. Note on URL regeneration: Some CMS platforms may regenerate previously deleted URLs, which can cause confusion about which URL is canonical and may unintentionally reinstate broken states. Audit URL changes carefully after content deletion to avoid link resurrection. 📊 How Do Broken Links Impact Your Website? SEO Impact - Waste crawl budget when bots follow dead ends. - Stop link equity transfer between pages. - Disrupt site crawlability and architecture. - Create JavaScript rendering issues on dynamic sites. 🧭 User Experience - Dead ends frustrate users and stop their journey. - Higher bounce rates from early exits. - Poor satisfaction and perception of site quality. - Issues can appear differently on mobile devices. Brand Reputation - Broken links make sites appear unprofessional. - Reduce trust with partners, journalists, or customers. - Signal neglect to both users and search engines. - Harm multilingual or international site credibility. 🛠️ How to Check for Broken Links With OTTO SEO - Detects redirects and broken links directly. - Recommends replacing old URLs with final versions. - Fixes implemented automatically without manual effort. With the Site Audit Tool - Scans your site for broken external and internal links. - Reports organize issues like crawlability, link errors, and indexability. - Identifies 404 errors and displays HTTP status reports for pages. With Site Lens - Detects broken internal links, broken backlinks, and orphan pages within the Search Atlas platform. - Surfaces link health alongside on-page and technical SEO signals. - Helps prioritize fixes across the site from a single dashboard. Alternative Tools - Online scanners for quick checks on small sites. - Browser extensions to spot issues during content reviews. - Command-line tools for automated workflows in development. Note on audit tool lag: Site audit tools (including Site Lens) may show a delay between when a 404 is resolved and when the tool updates its status. If a broken link or 404 still appears as unresolved despite Google indexing the page, trigger a manual recrawl. If the issue persists, contact support, as this may indicate a reporting discrepancy rather than an actual broken link. ⏱️ How Often Should You Check for Broken Links? - Large, frequently updated sites: Weekly or bi-weekly scans. - Smaller sites: Monthly checks. - All sites: Comprehensive quarterly audits. - After migrations or redesigns: Check all links within 48 hours. 🔧 How to Fix Broken Links ✅ Prioritize by impact – Fix high-traffic or conversion-critical pages first. ✅ Remove the broken link – Delete links with no replacement value. ✅ Redirect to a new URL – Use 301 redirects to preserve authority. ✅ Restore missing content – Publish replacement pages under the same URL. ✅ Contact site owners – Request updates to broken backlinks. ✅ Replace or remove external sources – Use alternative references if originals no longer exist. Track improvements with: - Crawl error reports (Google Search Console). - Bounce rates on fixed pages. - Organic traffic recovery. - Ranking performance after redirects. 🛡️ How to Prevent Broken Links - Use consistent URL structures – Avoid unnecessary changes. - Check links before publishing – Test them manually. - Run regular link checks – Use OTTO SEO or GSC. - Apply redirects thoughtfully – Match new destinations with original intent. - Monitor and update redirects – Retire old ones when no longer needed. ❓ FAQs ❓ What’s the most common cause of broken links? Deleted or moved content is the most frequent cause, especially during redesigns. ❓ Do broken links hurt SEO directly? Yes. They waste crawl budget, stop link equity flow, and harm site structure. ❓ How fast should I fix broken links after a migration? Run a full audit within 48 hours and fix immediately. ❓ Which is better: removing or redirecting a broken link? Redirect if relevant content exists, otherwise remove the link ✅ Final Takeaway Broken links are a normal part of any website’s lifecycle, but leaving them unchecked harms SEO, user experience, and brand trust. By running regular audits, fixing issues quickly, and setting up strong prevention practices, you can keep your site healthy and user-friendly. Staying proactive ensures visitors always find what they need — and search engines reward you for maintaining a seamless, reliable site.

🧱 How to Clear Cache in WordPress (Complete 2025 Guide)

When your WordPress site doesn’t show recent updates, caching is often the culprit. Cache helps speed up websites, but it can also store outdated versions of your pages. Here’s how to find and clear every layer of cache — from your hosting server to plugins and browsers — so your latest changes appear instantly. ⚙️ Step-by-Step Instructions 🏢 Step 1: Check for Server-Level Caching Most managed WordPress hosts automatically cache your website. Look for caching controls directly in your hosting dashboard. - WP Engine → Caching → Clear All Caches - SiteGround → Speed → Dynamic Cache → Flush Cache - Bluehost → Performance → Caching → Purge All If you don’t see these options, search your hosting help docs for “Flush Cache” or “Clear Cache.” 🌐 Step 2: Purge CDN Cache (Cloudflare or Similar) If you’re using Cloudflare, Akamai, or another CDN service: 1. Log in to your CDN account. 2. Go to the Caching tab. 3. Click Purge Everything. 4. Wait a few seconds, then reload your site to confirm. 👉 Resource: Cloudflare Docs – Purge Cache 💾 Step 3: Purge Object Cache (Redis / Memcached) Many hosting providers use Redis or Memcached to store database query results for faster performance. If you’re using one of these systems: 1. Go to WP Admin → Tools → Site Health → Info → Persistent Object Cache to confirm it’s active. 2. In your hosting control panel, look for Flush Object Cache or Clear Redis Cache. 3. On some platforms (like Kinsta, Cloudways, or RunCloud), this option appears directly on the site dashboard. 4. From the command line (WP-CLI), you can also run: 5. wp cache flush 👉 Resource: WordPress Developer Docs – Object Cache 🧭 Step 4: Clear Browser or Local Cache Sometimes, the “stuck” cache isn’t on your website — it’s in your browser. 1. Clear your browser cache and cookies. 2. Reload your site in Incognito/Private Mode to check the latest version. 3. Developers can use Chrome DevTools → Disable cache during testing. 👉 Resource: Google Chrome Help – Clear Cache & Cookies 🧰 Step 5: Manual Cache Purge (As a Last Resort) If your cache plugin or host-level purge doesn’t work, you can clear it manually: 1. Access your site via FTP or your hosting File Manager. 2. Navigate to: 3. /wp-content/cache/ 4. Delete all files and folders inside (but do not delete the main /cache/ folder itself). This forces WordPress to rebuild a fresh cache on the next page load. 👉 Resource: WordPress Advanced Admin – Cache 🔌 Step 6: Clear Cache Using Popular Plugins 🧩 WP Rocket - Go to Settings → WP Rocket → Dashboard. - Click Clear and Preload Cache. - Or, hover over the WP Rocket menu in your WordPress admin bar → choose Clear and Preload Cache. - Developers can purge cache programmatically with rocket_clean_domain() or rocket_clean_post(). 👉 Resource: WP Rocket Official Docs ⚡ W3 Total Cache (W3TC) 1. Navigate to Performance → Dashboard. 2. Click Empty All Caches. 3. Or use the admin bar → Performance → Purge All Caches. 4. Advanced users: run wp w3-total-cache flush all via WP-CLI. 👉 Resource: InMotion Hosting – W3 Total Cache Guide 🧹 WP Super Cache 1. Go to Settings → WP Super Cache. 2. Scroll to the Delete Cached Pages section. 3. Click Delete Cache to purge everything. 👉 Resource: Kinsta – WordPress Cache Guide 🪄 WP Fastest Cache 1. In your dashboard, open WP Fastest Cache → Delete Cache. 2. Click Delete Cache or Delete Cache + Minified CSS/JS if you changed styling or scripts. 👉 Resource: Hostinger Cache Tutorial 🔥 LiteSpeed Cache 1. Go to LiteSpeed Cache → Toolbox. 2. Click Purge Entire Cache. 3. You can also clear CSS/JS or Object Cache individually if needed. 👉 Resource: SupportHost – Clear Cache Guide 💡 FAQs ❓ Do I need to clear all caches every time I make a change? 💡 Not always. Most caching plugins and hosts auto-purge when you update a post, change your theme, or modify plugin settings. ❓ What’s the safest cache purge order? ⚙️ Always clear Hosting → CDN → Object Cache → Plugin Cache → Browser. ❓ My site still doesn’t update after clearing everything. What now? 🔍 Check your CDN cache headers or try forcing a hard refresh (Ctrl + Shift + R / Cmd + Shift + R). ✅ Closing Note Clearing cache regularly keeps your website updated and ensures visitors see the latest version of your content. If your site still doesn’t reflect recent changes, contact your hosting support — they may need to purge server-level caches manually. 🔗 Resources 👉 Resource: WordPress Developer Docs – Performance & Caching 👉 Resource: Cloudflare Docs – Purge Cache 👉 Resource: WP Rocket Official Documentation 👉 Resource: Kinsta WordPress Cache Guide 👉 Resource: Hostinger WordPress Cache Guide

🚀 How to Enhance Website Performance for Better Rankings

🧠 Overview Website speed is more than a convenience—it’s a critical factor in your site’s success. A delay of just a few seconds in page load time can mean lost visitors, lower conversions, and weaker rankings. In this guide, we’ll explore how to: - Improve website speed and performance - Optimize for both desktop and mobile users - Boost your visibility in Google search results - Align with Core Web Vitals for better SEO outcomes ⚡ Why Website Speed Is Crucial for Business Success Page Load Time Affects SEO Google prioritizes websites that provide exceptional user experiences, and speed is a big part of that. Faster sites rank higher because they load quickly, engage users longer, and reduce bounce rates. Google’s Core Web Vitals—Loading Time, Interactivity, and Visual Stability—play a vital role in determining SEO performance. The faster and more stable your website is, the better your chances of ranking well. Slow Load Times Cost You Revenue Speed isn’t just about SEO—it’s about business outcomes. Research shows: - 📉 Amazon loses 1% in revenue for every 100ms of delay - 🛒 Walmart sees a 2% increase in conversions per second of speed improvement - 🌍 Mozilla’s 2.2s boost in load time led to 10 million extra downloads annually - 💰 Shopzilla cut load times from 7s to 2s and saw a 50% drop in operational costs These examples highlight how performance directly influences growth and profitability. Search Engines Favor Fast Websites With mobile-first indexing, Google now primarily evaluates websites based on their mobile performance. That means optimizing your mobile experience isn’t optional—it’s essential. A fast-loading, mobile-friendly site ranks higher, attracts more visitors, and delivers a seamless user journey from search to conversion. The Ideal Load Time According to Google According to Google’s benchmarks: - Speed Index: 3 seconds or less - Request Count: Fewer than 50 requests per mobile page - Page Weight: Under 500KB Hitting these targets ensures faster load times and a better user experience across devices. 🧩 How to Improve Website Performance 1. Test Your Website Speed Start with an audit using Google PageSpeed Insights (PSI). - 90+ = Fast - 50–90 = Moderate - <50 = Slow PSI identifies bottlenecks such as unoptimized images, long JavaScript execution, and render-blocking resources—making it your first step toward improvement. 2. Switch to a Faster Web Host Your hosting environment heavily impacts load times. - Shared hosting can slow you down due to resource competition. - Dedicated or cloud hosting ensures stable, faster performance. For growing sites, cloud solutions provide scalability and higher reliability during traffic spikes. 3. Optimize Your Website Theme If you use a CMS like WordPress: - Choose a lightweight, SEO-friendly theme. - Remove unnecessary widgets and plugins. - Keep code clean to improve speed and stability. 4. Minimize HTTP Requests Fewer requests mean faster pages. Reduce load time by: - Combining CSS/JS files where possible - Avoiding unnecessary redirects - Updating internal links to point directly to target URLs 5. Compress Files Use tools like Gzip or Brotli to compress your HTML, CSS, and JavaScript files. Compression can cut response times by up to 70%, especially on content-heavy pages. 6. Optimize Images and Media Large files often cause slowdowns. Follow these best practices: - Use JPEG for rich photos, PNG for graphics - Resize to correct display dimensions - Compress images with TinyPNG, JPEGmini, or ShortPixel - Enable lazy loading for below-the-fold visuals 7. Implement a Content Delivery Network (CDN) A CDN distributes your website’s files across multiple servers worldwide, delivering content from the closest server to the user. Benefits include: ✅ Faster global load times ✅ Reduced latency ✅ Greater scalability during traffic surges ✅ Improved uptime and reliability 8. Review and Clean Up Plugins Regularly remove outdated or unused plugins. Each adds code that can slow your site and introduce vulnerabilities. Fewer, high-quality plugins = faster load times and stronger security. 9. Minify Code Minify your HTML, CSS, and JS files using tools like: - UglifyJS (JavaScript) - CSSNano (CSS) This removes unnecessary characters and spaces, shrinking file sizes and speeding up rendering. 💬 Frequently Asked Questions Why is website performance important for user experience and SEO? A fast, reliable website keeps users engaged and satisfied. Search engines reward sites that provide excellent user experiences, so improving speed enhances both SEO rankings and trustworthiness. What are some simple ways to improve website loading speed? - Optimize and compress images - Enable lazy loading - Minify code (HTML, CSS, JS) - Use browser caching - Implement a CDN for faster global delivery Each of these steps can significantly reduce load times and improve site usability. How do images affect website performance, and how can I optimize them? Unoptimized images slow down load times. To fix this: - Resize to match display dimensions - Use proper formats (JPEG, PNG, WebP) - Compress without losing quality - Implement lazy loading - Serve images through a CDN These steps keep your visuals crisp without sacrificing performance. What is a Content Delivery Network (CDN), and how does it improve website performance? A CDN stores copies of your website across global servers and serves content from the nearest one to each visitor. This reduces latency, speeds up page load, and improves stability during high-traffic events—making it one of the most effective performance solutions. How do Google’s Core Web Vitals affect my website’s SEO? Core Web Vitals measure: - LCP (Largest Contentful Paint): Loading speed - FID/INP: Interactivity and responsiveness - CLS (Cumulative Layout Shift): Visual stability Optimizing these metrics helps you rank higher and deliver smoother user experiences, which in turn strengthen SEO performance. What tools can I use to measure and monitor my website’s performance? Use a combination of analytics and SEO tools to stay on top of your site’s health: - Google PageSpeed Insights – Measures speed and Core Web Vitals - Google Analytics – Tracks engagement and session behavior - Ahrefs / SEMrush – Monitors SEO and keyword performance - Hotjar / Crazy Egg – Provides user behavior heatmaps Regular audits ensure your site stays optimized, fast, and competitive. 🎯 Final Thoughts Improving website performance isn’t just a technical exercise—it’s a strategic advantage. A faster website means: - Higher SEO rankings - Better user experience - Increased conversions and engagement By optimizing images, compressing files, leveraging CDNs, and monitoring Core Web Vitals, your site can achieve the seamless performance both users and search engines expect.

📘 Why Am I Seeing Pages I Don't Recognize Being Crawled on My Site?

If you've noticed a large number of unfamiliar pages being crawled on your site—such as URLs with /author/, /category/, /tag/, or /date/—this is actually quite common. These URLs are typically auto-generated by your content management system (CMS), especially if you're using platforms like WordPress. This article will help you understand what these pages are, why they're being crawled, and how to control their visibility. 👣 Step-by-Step Instructions 1. What Are These Pages? Many CMSs, including WordPress, automatically generate archive pages you may not have manually created: - Author Archives – Lists all posts by a specific author (e.g., /author/admin/) - Date Archives – Groups content by month or year (e.g., /2023/07/) - Category Pages – Lists posts under a specific category (e.g., /category/news/) - Tag Pages – Shows content tagged with a specific keyword (e.g., /tag/seo/) These pages are public by default and can be discovered by any crawler or search engine. 2. Why Are These Pages Being Crawled? 1. Crawlers scan all publicly accessible pages. 2. If these archive pages are linked internally (e.g., sidebar, footer, sitemap), they're considered part of your site's structure. 3. Unless deliberately disabled or blocked, they will continue to exist and be crawled. 3. How Can I Control This? 1. Disable in CMS Settings - Many platforms let you turn off author archives, date archives, or other taxonomy pages directly from site settings. For example, in WordPress, navigate to Yoast SEO > Search Appearance > Archives to disable author and date archives. Other SEO plugins such as Rank Math offer similar settings under Titles & Meta > Archives. 2. Block Crawling with robots.txt - Add rules to disallow specific paths. For example, to block author and tag archives, add the following to your robots.txt file: User-agent: * Disallow: /author/ Disallow: /tag/ Disallow: /category/ - Important: robots.txt only prevents crawling—it does not guarantee de-indexing. If the URLs are linked externally, they can still appear in search results. To prevent indexing, you'll need a noindex meta tag or HTTP header. In some cases, you may need to use both methods together depending on your goal. - Add noindex Meta Tags - If you want the pages to exist but not appear in search results, configure your site to apply a noindex tag. - This lets them be crawled but prevents indexing. 3. Audit Your XML Sitemap - Customers often inadvertently include tag, category, or author URLs in their XML sitemap, which amplifies crawl budget waste. Review your sitemap and remove auto-generated archive URLs if they aren't intended to be indexed. Most SEO plugins (Yoast SEO, Rank Math, All in One SEO) let you exclude specific taxonomies from the sitemap under their sitemap settings. 4. Using Search Atlas OTTO & Site Lens - OTTO Site Audit and Site Lens may surface these archive/auto-generated URLs as orphan pages or unindexed pages. If they're intentional, you can mark them as excluded so they don't continue to appear as issues. - If available, use OTTO's robots.txt manager to apply the disallow rules described above without editing your server files directly. - Monitor crawl coverage in Site Lens over time to confirm that excluded URLs are no longer being prioritized by crawlers. ❓ FAQs ❓ Why do these pages exist if I didn't create them? 💡 Your CMS automatically generates them as part of its default functionality. ❓ Should I block or keep these pages? ⚡ If they don't serve SEO or user navigation purposes, it's often best to block or noindex them. ❓ What happens if I disable them? ✅ They'll no longer be accessible, meaning crawlers and users won't see them. ❓ I use Landing Page Studio with a custom domain — why are new pages appearing in crawl data so quickly? 🚀 If you're using Landing Page Studio with a custom domain and have Instant Indexing enabled, newly published pages are automatically submitted to Google. Seeing them appear quickly in crawl logs is expected and intentional behavior. ❓ Site Lens still shows orphan pages as unresolved even after I've fixed them — what should I do? 🔄 If Site Lens shows orphan pages as unresolved even after Google has indexed them, this may be a known display sync issue. Try performing a manual recrawl and verify the page's indexed status directly in Google Search Console. If the issue persists, contact support. Closing Note ✅ These unfamiliar URLs are usually nothing to worry about—they're simply auto-generated by your CMS. By adjusting settings, updating your robots.txt, or applying meta tags, you can take control over whether they're crawled or indexed.

🔍 Site Lens: Visualizing Your Site Architecture Like Never Before

Site Lens is Search Atlas' advanced visualization layer, designed to transform raw crawl data into clear, actionable visual intelligence. Instead of scanning tables of URLs, Site Lens lets you see your site's structure, crawl behavior, internal linking, and topical coverage across multiple visual dimensions. This guide explains every Site Lens visualization, how it works, where it lives in the product, and what insights to look for. 📍 How to Access Site Lens Site Lens lives inside OTTO SEO → Site Audit → Site Lens: from OTTO SEO, open Site Audit, then open Site Lens for your project. Once loaded, you'll see the project name, total pages crawled, six visualization tabs (2D Node Cluster, 3D Crawl Diagram, Tree Diagram, Crawl Tree, Link Flow Diagram, LDA Topic Analysis), and global filters and export options. 🧠 What All Site Lens Views Have in Common - Each node represents a page - Connections represent internal links - Node size reflects the selected metric (traffic, impressions, keywords, etc.) - Node color reflects depth or health - Filters allow you to isolate sections, hide pages, or emphasize specific page types These views are different ways of looking at the same crawl data, each optimized for a different kind of insight. 🧭 Global Controls Left control panel: Go to URL (jump to and highlight a specific page), Fix nodes on drag (lock node position), Show labels (toggle URL labels), Size by (choose the metric that controls node size — Depth, Traffic, Impressions, Keywords, etc.), Color by (choose color metric — Depth, Page Health Score), Emphasis (highlight hubs, traffic leaders, paid pages), Max Depth (limit crawl depth shown), Link Length (spacing between nodes), and Reset (restore default view). Top controls: Filter Pages (isolate specific sections), Show Prunable (highlight low-value pages), Hide Orphans (hide disconnected pages), Export PNG (download the visualization), and Light / Dark Mode. 🟢 2D Node Cluster A force-directed graph showing your site's pages as interconnected nodes in a two-dimensional space. Each node is one page, lines are internal links, and nodes naturally group into clusters based on linking relationships. The homepage typically appears near the center. How to read it: node size reflects the selected metric; node color reflects crawl depth from the homepage (depth 0 = homepage, depth 1 = first-level pages); blue rings mark hub or emphasized pages; red rings mark pages flagged as prunable; dense clusters indicate strong topical or structural grouping; isolated nodes indicate orphan or weakly linked pages. What it helps you detect: pages that are hard for search engines to discover, important content with insufficient internal links, over-isolated sections, pages that add little SEO value, and hubs that aren't distributing authority effectively. Recommended actions: add internal links to isolated or deep pages, strengthen hub pages and link them to priority URLs, consolidate or prune low-value pages, rebalance internal linking across clusters, and align architecture with content strategy. 🟣 3D Crawl Diagram An immersive, three-dimensional view of your site structure, with pages represented as spheres in 3D space, internal links connecting pages, and depth visualized spatially. The homepage typically sits near the center. How to read it: vertical spread shows hierarchy depth; dense regions are strongly linked sections; floating nodes are weakly linked pages; larger spheres reflect higher metric values. What it helps you detect: excessively deep site architecture, pages buried too far from the homepage, structural bottlenecks, and hidden clusters not obvious in 2D views. Recommended actions: flatten deep sections where possible, add shortcut links to buried pages, strengthen internal linking to floating nodes, and validate architecture changes visually. 🌳 Tree Diagram A hierarchical view based on URL structure, showing parent-child relationships derived from URL paths, sections and subsections of your site, and page counts per section. How to read it: top nodes are higher-level pages; deeper branches are nested URLs; wide branches are large sections; collapsible nodes are expandable subsections. What it helps you detect: pages buried too deep in the URL structure, overcrowded sections, unbalanced or confusing hierarchies, and structural inconsistencies. Recommended actions: simplify deep URL paths, reorganize oversized sections, improve navigation and breadcrumbs, and align URL structure with content intent. 🌲 Crawl Tree A visualization of the actual crawl path taken by search engines: real crawl discovery order, parent-child crawl relationships, crawl depth from the homepage, and pages flagged as prunable. How to read it: left-to-right flow shows crawl progression; deeper levels mean more clicks required; highlighted nodes indicate low-value pages. What it helps you detect: important pages discovered too late, crawl inefficiencies, pages requiring too many clicks, and weak internal link signals. Recommended actions: reduce crawl depth for priority pages, add internal links earlier in the crawl path, remove unnecessary crawl paths, and improve crawl efficiency. 🔗 Link Flow Diagram A visual map of how internal link equity flows between sections: site sections arranged in a circular layout, ribbons representing internal links, and ribbon thickness indicating link volume. How to read it: thick ribbons show strong link flow; thin or missing ribbons show weak connections; balanced sections indicate healthy architecture. What it helps you detect: siloed content, uneven authority distribution, and missed cross-linking opportunities. Recommended actions: add links between related sections, strengthen authority flow to priority areas, and balance internal linking strategy. 🧩 LDA Topic Analysis A semantic view of what your content is actually about: topics represented as bubbles, topic size reflecting prevalence, keywords associated with each topic, and pages probabilistically mapped to topics. How to read it: large bubbles are dominant topics; overlapping bubbles are related themes; distant bubbles are distinct topics. What it helps you detect: overlapping or redundant content, missing topical coverage, and weak topical authority areas. Recommended actions: fill content gaps, consolidate overlapping articles, strengthen internal linking within topics, and align content with search intent. 🎯 Why Site Lens Matters Site Lens turns SEO from analysis into visual understanding. By combining crawl depth, internal links, hierarchy, link equity, and topical relevance, Site Lens gives you a complete mental model of your website — exactly as search engines experience it. Site Lens is not one visualization — it's six complementary lenses on the same truth. Your site's structure determines how value flows, how pages rank, and how content is discovered. Use Site Lens to find what's hidden, fix what's broken, strengthen what matters, and build with intention. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🕷️ Whitelisting the Search Atlas Crawler & Accessing kgraph for Agentic Certification

Whitelist the Search Atlas crawler in your firewall or security plugin so site audits run without interruption. If you are completing the Agentic Mastery certification, this article also includes the updated kgraph URL. 🔒 Search Atlas Crawler IP Addresses Search Atlas uses the following IP addresses to crawl and monitor websites. Whitelist all 20 addresses to ensure site audits complete successfully. - 168.151.102.206 - 161.123.88.40 - 161.123.75.228 - 161.123.90.214 - 161.123.81.184 - 168.151.116.203 - 168.151.138.43 - 161.123.105.249 - 161.123.77.229 - 161.123.107.109 - 161.123.77.171 - 161.123.90.252 - 209.95.170.40 - 168.151.116.237 - 161.123.78.218 - 161.123.104.45 - 161.123.85.66 - 161.123.82.188 - 209.95.171.24 - 161.123.83.48 ☁️ How to Whitelist the Search Atlas Crawler in Cloudflare Cloudflare is the most widely used CDN (Content Delivery Network). If your site runs behind Cloudflare, its firewall may block the Search Atlas crawler. Follow these steps to add the Search Atlas IP addresses to your Cloudflare allowlist. 1. Log in to your Cloudflare account. 2. Click the Firewall icon, then select the Tools tab. 3. Under IP Access Rules, enter each Search Atlas IP address from the list above. 4. Set the action to Whitelist. 5. Select the domain you want the Search Atlas crawler to access. 6. Click Add. Once all IP addresses are added, the Search Atlas crawler can access your site for monitoring and audits. For more detail on Cloudflare's IP Access Rules, see Cloudflare's support documentation. If you are still unable to run a site audit after whitelisting, contact our support team via the in-dashboard chat (Monday–Friday, 9 am–6 pm PST), or book a software demo with our team. 🔌 How to Whitelist the Search Atlas Crawler in WordPress Security Plugins If your site uses a WordPress security plugin rather than Cloudflare, follow the steps for your plugin below. WordFence 1. In the WordPress menu, go to WordFence → Firewall → All Firewall Options. 2. Paste the Search Atlas IP addresses into the Allowlisted IP addresses that bypass all rules field. 3. Click Save Changes. Stop Bad Bots 1. In the WordPress menu, go to Block Bad Bots → Settings. 2. Select the Whitelist tab. 3. Paste the Search Atlas IP addresses into the IP Whitelist field. 4. Click Save Changes. Blackhole for Bad Bots In the Blackhole for Bad Bots plugin settings, add each Search Atlas IP address to the plugin's whitelist field and save. The crawler will be allowed through on your next audit. 🧠 Accessing kgraph for Agentic Mastery Certification If you are completing the Agentic Mastery certification and the kgraph link on Day 2 does not load, the legacy URL kgraph.searchatlas.com has been deprecated. Use the updated URL instead: https://kgraph.labs.searchatlas.com/ If you still cannot access the kgraph subdomain after switching to the new URL, contact Search Atlas support via the in-dashboard chat and our technical team will assist you. 🎯 You can now unblock the Search Atlas crawler for site audits and reach the kgraph training environment. For additional troubleshooting, refer to the Whitelisting Search Atlas Bot article if the steps above do not resolve your issue.

🔗 How It Works: URL Indexer

🔗 What It Is The URL Indexer submits your URLs to Google to encourage faster indexation. Instead of waiting for Google to discover and index new pages, backlinks, or refreshed content on its own, you can submit them directly through the Search Atlas URL Indexer to help them get crawled and indexed sooner. It's designed for pages that need to appear in search results quickly — newly published articles, backlinks from cloud stacks or press releases, fresh product pages, or other URLs Google hasn't yet picked up. ⚙️ What It Does - 🚀 Submits batches of URLs to Google to support accelerated indexation - 📊 Tracks the indexation status of every submitted URL - 📋 Generates a detailed indexation report (indexed vs. not-indexed) - 🔗 Works with the URLs you submit, including your own pages and the backlinks pointing to them 🧩 What You Need - 📝 A list of URLs (manual entry or CSV upload) - 🌐 Each URL must start with http:// or https:// - 💳 Universal Credits — to cover the submission cost (priced per URL) 🚀 How to Index URLs 1️⃣ Option 1: Manual Submission - 🔗 Open Authority → Indexer (URL Indexer) in your dashboard - ➕ Click Index URLs and give it a name (e.g., "October Backlinks" or "New Blog Posts") - 📝 Paste your URLs into the input field — one per line - 💳 Confirm the cost and submit - 📊 The batch enters the Pending → Submitted → Indexing pipeline ✅ Best for: small lists, ad-hoc submissions, single-page indexing. 2️⃣ Option 2: CSV Upload - 📄 Prepare a CSV file with one URL per row (no headers needed, just the URLs) - 🔗 Open Authority → Indexer (URL Indexer) and click Index URLs - 🏷️ Name your batch - ⬆️ Upload the CSV file - 🔍 The system parses every URL, validates the format, and shows you the count and cost before submission - 💳 Confirm and submit ✅ Best for: large lists, bulk backlink indexing, recurring indexing workflows, agency-scale operations. ⚠️ Check your dashboard for any per-batch size limits before submitting large lists. 📊 The Indexing Pipeline 📥 Submission URLs are validated and queued for processing. ⚙️ Processing The indexer submits each URL to Google's indexation pipeline. 📊 Status moves through: Pending → Submitted → Indexing → Indexed / Not Indexed 👀 Tracking You can check batch progress at any time and see URL-level status — which URLs are indexed, still pending, or failed. 📋 Reporting A complete CSV report is generated after the indexation cycle, showing the final status of every URL. 📈 What You Get - 🚀 Faster indexation — pages can be picked up by Google sooner than waiting for organic discovery - 👀 URL-level visibility — see exactly which URLs got indexed - 📄 Downloadable reports — full CSV of every batch result - ⚡ No manual Google Search Console work — bulk submission without inspecting URLs one-by-one - 🔗 Higher backlink ROI — links can't pass authority until they're indexed ✅ Best Practices - 🚀 Submit URLs as soon as they go live — don't let new pages sit unindexed - 🏷️ Group similar URLs into named batches (e.g., by campaign, content type, or month) for easy tracking - 🔄 Re-index after major content updates - 🔗 For backlinks, submit both the backlink URL and the linked page for full impact - 📄 Use CSV upload for large lists — faster, cleaner, and less error-prone than manual paste - 👀 Check status before submitting again — duplicate submissions waste credits

🔐 A Guide to HTTP vs HTTPS Protocols and More

🚀 The Revolution of Data Markup: Page-Specific Schema and the End of “Schema Decay”

This article explores how AI has transformed structured data implementation from static templates to deep contextual understanding. For years, structured data has been one of the most misunderstood, and most poorly maintained, parts of SEO. While schema markup was designed to help search engines understand content, the way it has traditionally been implemented has created a long-term problem: schema decay. Search Atlas introduces a fundamentally different approach: AI-driven, page-specific schema, built from real contextual analysis instead of static templates. 🧩 Why “Schema Decay” Happens Historically, schema implementation has been treated as a one-time setup task. Developers hard-code markup into templates or individual pages, deploy it, and then move on. The problem is that websites are not static. Over time: - Prices change - Services evolve - Reviews accumulate - Content gets updated But the schema often stays exactly the same. As a result, the structured data no longer reflects the reality of the page. This mismatch between visible content and structured data is what we refer to as schema decay. It creates ambiguity for search engines and undermines the very purpose of schema in the first place. Manual maintenance doesn’t scale, and most teams simply don’t have the time, or the visibility, to keep schema perfectly synchronized across thousands of pages. 🤖 How Search Atlas Solves Schema Decay with AI Search Atlas approaches schema as a dynamic representation of page understanding, not a static block of code. Instead of relying on templates, the platform uses AI to analyze each individual page and extract its full context, including: - Entities - Page intent - Content structure - Business attributes - Relationships between data points This analysis is performed at the page level, which allows Search Atlas to generate schema that is specific, accurate, and aligned with what actually exists on that URL. The system supports over 1,000 schema types, including more than 200 niche local business subtypes, spanning industries from healthcare and legal services to aviation and specialized professional services. This level of granularity makes it possible to represent businesses and content far more accurately than generic schema templates ever could. 🧠 From Static Markup to Pre-Computed Understanding Schema, in this model, is not just markup, it’s a pre-computed understanding of the page. Search Atlas builds this understanding by analyzing the page content, mapping it to the correct schema types, filling required and recommended fields using contextual signals, and validating the structure before deployment. Inside the platform, users can review the generated schema, audit it, and make adjustments when needed. This creates transparency and control without reintroducing the maintenance burden that causes schema decay in the first place. ⏱️ Why Manual Schema Management Doesn’t Scale The operational cost of manual schema becomes clear at scale. On a site with approximately 5,000 pages, deploying 8 to 10 unique schema types per page would require an estimated 2,000 to 4,000 hours of work, the equivalent of one to two full-time employees for an entire year. And that effort doesn’t even account for ongoing updates as content changes. Search Atlas automates this entire process. What would normally take months of manual work can be analyzed, generated, and deployed in seconds, with consistency across the entire site. 📊 Real-World Impact: What the Data Shows Search Atlas conducted an impact analysis across 22,000 connected sites to measure the effect of AI-driven, page-specific schema fixes. The results showed a strong correlation between proper schema implementation and significant organic visibility gains, including an average 110% increase in total ranking keywords, noticeable improvements in impressions, and increased click activity across indexed pages. While schema alone is not a ranking factor, these results highlight its role as a visibility amplifier when search engines can accurately interpret page content. 🔍 Supporting Infrastructure: Real-Time Crawl Logs To support this system, Search Atlas also provides real-time crawl logs, allowing users to see how search engines are interacting with their pages as crawls happen. This visibility helps teams identify crawl issues immediately, confirm that schema-enhanced pages are being accessed correctly, and validate status codes and crawl behavior at scale. Together, page-specific schema and crawl visibility form a closed feedback loop between understanding, execution, and verification. 🚀 Bulk Deployment Without the Risk Even with this level of precision, Search Atlas is built for scale. Users can review schema suggestions in bulk, select multiple pages at once, and deploy schema across hundreds of URLs with a single action. When schema suggestions are generated using AI, the system clearly indicates AI credit usage, keeping execution transparent and predictable. 🏁 The End of Schema Decay Schema decay is not a tooling problem, it’s a methodology problem. By replacing static templates with AI-driven, page-level analysis, Search Atlas transforms structured data into a living system that evolves alongside your site. The result is schema that stays accurate, relevant, and aligned with real content, without the operational overhead that has historically made schema such a fragile part of SEO. This is what schema was always meant to be: a faithful representation of meaning, not a forgotten block of 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.

⚡ The Complete Guide to Indexing in Search Atlas (Instant, Dynamic & Authority Indexer)

Search Atlas gives you multiple indexing workflows, each designed for different SEO scenarios. If you’ve ever published a page and waited days (or weeks) for Google to crawl it… this is where that waiting stops. This guide explains: - 🔥 Instant Indexing (real-time submission) - 🧠 Dynamic Indexing (re-submit pages that are indexed but receiving zero impressions in Google Search Console, so Google re-evaluates and potentially ranks them) - 🏗 Authority → URL Indexer (batch submission workflow) - 🛠 Advanced strategies & troubleshooting 📍 Navigation Paths Instant Indexing: Left Sidebar → OTTO SEO → All Sites → Select your Site → Scroll to Recommendations → Left Panel → Indexing → Instant Indexing Dynamic Indexing: Left Sidebar → OTTO SEO → All Sites → Select your Site → Scroll to Recommendations → Left Panel → Indexing → Dynamic Indexing Authority → Indexer (URL Indexer): Left Sidebar → Authority → Indexer (URL Indexer) 🚀 What Is Instant Indexing? Instant Indexing connects directly to: - Google Search Console (GSC) - Bing IndexNow It allows you to submit URLs immediately for crawling and indexing. Instead of waiting for Google to “discover” your page, you notify search engines proactively. 🧩 Two Methods Inside Instant Indexing 1️⃣ Sitemap-Based Indexing Submit entire sitemaps for indexing. You’ll see: - Pages count - Awaiting Indexation - Indexed - GSC / IndexNow toggles - Add Sitemap option About the GSC / IndexNow toggles: Toggle GSC on to submit via Google Search Console. Toggle IndexNow on to simultaneously notify Bing. Both can be enabled at the same time for maximum coverage. Best for: - Large websites - Ecommerce - CMS with structured sitemaps - Ongoing indexing management 2️⃣ Custom URL-Based Indexing Submit specific URLs manually. You can: - Add individual URLs - Perform bulk actions - Toggle GSC or IndexNow - Track submission status IndexNow submission statuses (recently added): Submissions now display an explicit status — accepted, pending, or failed. If a submission shows as failed, retry the submission; if it continues to fail, contact support so we can investigate. Best for: - New blog posts - Updated landing pages - Time-sensitive content - Campaign launches 🔗 Connect Google Search Console (GSC) for Instant Indexing Instant Indexing can submit URLs to Google (via GSC) and Bing (via IndexNow). GSC and IndexNow can be toggled independently per sitemap or URL submission. To submit to Google, Search Atlas needs the correct permission level inside your Google Search Console property. ✅ What you’re actually doing You’re granting Search Atlas access to submit indexing requests on your behalf. That permission is tied to the exact GSC property you connect (usually your domain property). In the UI, this appears as an “Enable indexing access” prompt. 📍 Where this setup appears Inside Instant Indexing, you’ll see a setup panel/modal titled: Enable indexing access It has a simple 2-step flow. Step 1 — Copy your unique address You’ll see a field labeled something like: Copy your unique address - You can click Generate (to create one automatically), or paste an existing one if you already have it. - Then copy it using the copy icon. Think of this as the “account identifier” Search Atlas needs to be added into your GSC property. Step 2 — Add it to your Google Search Console property as an Owner Right below, the UI tells you exactly what to do: 1. Click Open GSC 2. In Google Search Console, open the correct property (commonly a domain property like sc-domain:yourdomain.com) 3. Go to Settings → Users and permissions 4. Click Add user 5. Paste the unique address you copied 6. Set permissions to Owner Why Owner matters: Instant Indexing needs the ability to submit indexing actions consistently across the property. Lower permission levels can cause verification failures or partial capability. Final step — Verify & enable access Back in Search Atlas, click: ✅ Verify & Enable access If successful, Search Atlas confirms indexing access and Instant Indexing can begin submitting requests. Common GSC setup mistakes (and how to avoid them) ❌ Adding the user to the wrong property Make sure you’re adding it to the exact property you’re indexing (domain vs URL-prefix matters). ❌ Not using Owner permissions If it’s not Owner, verification may fail or submissions may not work reliably. ❌ Multiple GSC accounts / wrong Google login If you’re logged into several Google accounts, GSC might open the wrong one. Confirm you’re in the correct account before adding permissions. 🔵 Bing IndexNow Setup Bing IndexNow is a separate channel from Google. It requires you to prove domain ownership by hosting a verification key on your website. In the UI, this appears as a modal titled: API key ✅ What you’re doing You’re adding an IndexNow API key to your website so Bing can verify that Search Atlas is allowed to submit URLs for that domain. Step 1 — Copy your API key You’ll see a field labeled: API Key Copy the key shown there. Step 2 — Host your API key at your domain root The UI describes two methods: Manual Installation and 1-Click Install (if eligible). ✅ Manual Installation (works for any site) You must create a plain text file and upload it to the root of your website. Rules that must be followed exactly: - Create a UTF-8.txt file - Filename must be the API key (exactly) - File content must be the same API key (exactly) - Upload it to your site’s root (top-level directory) 🎯 Instant Indexing in Landing Page Studio (LPS) When publishing a site in Landing Page Studio, users with a custom domain will see an opt-in Instant Indexing toggle directly in the Publish flow. What it does: When enabled, Search Atlas automatically submits the published URLs for indexing as soon as the site goes live — so you don’t have to add them manually inside Instant Indexing afterward. Important: This toggle is gated to custom domains. If you’re publishing on a default Search Atlas subdomain, the toggle will not appear in the Publish flow. 🧠 Dynamic Indexing What it is Dynamic Indexing identifies pages on your site that have been indexed but are receiving zero impressions in Google Search Console, and re-submits them to prompt Google to re-evaluate and potentially rank them. How to use it 1. Navigate to OTTO SEO → All Sites → select your site → Recommendations → Indexing → Dynamic Indexing. 2. Search Atlas will surface eligible URLs (indexed but zero impressions). 3. Review the list and submit the pages you’d like Google to re-evaluate. Best use cases - Pages that are technically indexed but “invisible” in search - Older content that has gone stale in rankings - Pages updated with new content that need to be re-evaluated - Sites with long-tail pages that struggle to gain visibility 🏗 Authority → URL Indexer (Batch Submission Workflow) What it is The URL Indexer (inside Authority Building) lets you submit URLs in batches for indexing. It’s designed for higher-volume workflows where you need to push many URLs through at once. Batch submission workflow 1. Go to Left Sidebar → Authority → Indexer (URL Indexer). 2. Paste or upload your list of URLs. 3. Start the batch job. Search Atlas processes the URLs and submits them for indexing. Credit usage Each URL submitted through URL Indexer consumes credits from your account. See the Credits & Billing section below for details on how credits are consumed and what to do if you lose credits to an error. Status tracking Each URL in a batch shows its current submission state so you can see what has been processed and what is still in progress. 💳 Credits & Billing (URL Indexer) How credits are consumed Each URL submitted through the Authority → URL Indexer consumes credits from your account balance. Credits are deducted at the time the job runs. What happens if a job fails or errors mid-run If a job fails part-way through, or if a platform error (for example, an Atlas Brain connection error) causes a job to be retried, credits may still be consumed across each run. This can result in credits being spent on incomplete or duplicated work. Requesting a credit refund If credits were consumed due to a platform error (not user action), contact Search Atlas Support with: - The date/time of the affected job - The number of credits consumed - A brief description of the error you encountered Support will investigate and, if confirmed, refund the credits to your account. 🛠 Troubleshooting & Known Issues Custom URL submissions not visible in the list If you add a URL via Custom URL-Based Indexing and it does not appear in the list immediately, this is a known display/refresh issue. Your URL has been submitted — use the search bar at the top of the list to confirm it is present. A fix is in progress. Submission limits & quotas Indexing capacity has recently been expanded across the platform. For current submission limits or quota questions specific to your account, please contact Search Atlas Support.

🔍 Forensic Auditing in Real Time: Clearing Out Cobwebs and Technical Debt

Modern websites accumulate technical debt quietly. Forgotten URLs, outdated test pages, low-value archives, and misconfigured redirects often live unnoticed inside a CMS, slowly draining crawl budget, internal link equity, and indexing efficiency. Traditional SEO audits surface these issues only after a crawl finishes, making it difficult to understand how and why they were discovered in the first place. Search Atlas provides real-time crawl monitoring and forensic page analysis, allowing teams to watch a crawl unfold live, identify hidden “cobwebs,” and trace their technical impact at the exact moment they are discovered. 🧠 Live Crawl Logs — See Your Site the Way Crawlers Do Search Atlas provides Live Crawl Logs, a real-time record of a site audit as it happens. During a crawl, the platform surfaces every discovered URL, HTTP status codes (200, 301, 404), and exact timestamps for each discovery. This live feed removes the black box from technical auditing. Instead of waiting for a crawl to finish, teams can immediately see which sections of the site are being explored, where crawl budget is being spent, and whether unexpected URLs are being indexed. This is especially valuable for large sites, enterprise environments, and long-lived WordPress installations. 🕸️ Identifying “Cobwebs” That Steal Equity One of the most powerful outcomes of live crawl visibility is the ability to surface forgotten or low-value pages that silently compete with your most important URLs. Common examples include old test URLs, default CMS pages, auto-generated date, tag, or archive pages, and thin internal landing pages that were never deprecated. These pages consume crawl budget, receive internal links, dilute link equity away from money pages, and increase indexing noise. By exposing these URLs in real time, Search Atlas allows teams to identify and act on technical debt before it compounds further. 🔬 Page Explorer — URL-Level Forensic Analysis Every URL surfaced in the live crawl log links directly to Page Explorer, where teams can perform deep, forensic analysis on individual pages. Page Explorer provides indexability status, HTTPS and protocol resolution, status code validation, download and response time metrics, sitemap inclusion checks, and internal and external link analysis. A key differentiator is incoming internal link visibility. Because Search Atlas performs a full crawl, it can identify exactly which internal pages link to a given URL, a level of insight that is impossible without crawling the entire site. This makes it easy to diagnose why low-value pages continue to receive authority and how equity flows through the site. When connected to first-party data sources, Page Explorer can also surface Search Console performance, click-through rates and positions, and analytics-based engagement and revenue signals, so teams can prioritize fixes based on technical impact and business value, not just crawl errors. ⚙️ JavaScript Rendering — Crawl Like Googlebot For modern, JavaScript-heavy sites and single-page applications, Search Atlas includes an optional JavaScript rendering toggle. When enabled, the crawler processes HTML, CSS, and JavaScript, so the audit reflects exactly what Googlebot sees, ensuring client-side rendered content, injected elements, and dynamic changes are fully evaluated. JS rendering should only be enabled when needed, as it increases crawl time. It is automatically enabled when required (for example, pixel-based implementations). Server-side rendered environments (WordPress plugin or Cloudflare integration) do not require JS rendering, since changes are already present in the initial HTML. 🔎 Why This Matters for Technical SEO and AI Search Real-time crawl logs and forensic page analysis are more than convenience features, they are foundational infrastructure for modern SEO. They allow teams to detect technical debt early, eliminate crawl waste, preserve internal link equity, improve indexing clarity, and reduce noise for search engines and AI systems. In an environment where both search engines and large language models favor clean, structured, and unambiguous sites, understanding how your site is crawled, as it happens, is no longer optional. Search Atlas turns site auditing from a static report into a live diagnostic system, giving teams the visibility they need to keep websites technically healthy at scale. If you need further assistance, open 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 recrawl an existing site in Search Atlas (Site Auditor)

If you've made changes to your website and want Search Atlas to scan it again, you can easily launch a new crawl using the Recrawl option inside Site Auditor. Running a recrawl helps refresh your audit data so you can review updated insights, monitor site health, and confirm whether recent site changes are being reflected in your audit results. 🧭 Where to Find the Recrawl Option All Audits list showing site cards To recrawl an existing site: go to the left sidebar and click OTTO SEO, then under Site Audit click All Audits, and find your site in the list. Each site appears as a card with key metrics and a View Audit button. 🛠️ How to Start a Recrawl Recrawl option in the site card dropdown Once you're on the OTTO SEO → Site Audit → Overview (Website Overview) page, click the Recrawl Site button directly. This immediately starts a new crawl for the selected site. 🧩 You Can Also Recrawl from the Audit Overview Recrawl Site button on the Audit Overview page If you click View Audit, the audit Overview page opens. From there, you can also find the Recrawl Site option in the top area of the audit view — handy if you're already reviewing your site audit and want to relaunch the crawl without returning to the All Audits page. 📈 What Happens After You Click Recrawl Once the recrawl begins, Search Atlas starts a new crawl for that site. You can remain on the page and monitor the crawl as it progresses — the site card updates its crawl status, and during an active crawl you may see Live Crawl Logs appear on the card. ⚙️ Optional but Recommended: Update Crawl Settings First Crawl Settings menu option Crawl Settings panel with Max Pages and Crawl Frequency Before launching a recrawl, you may want to adjust your crawl settings to better match your current audit needs. Click the site's three-dot menu and select Crawl Settings. From there, you can configure Max. Pages to Crawl (for example, 100 pages) and Crawl Frequency (for example, Weekly). Click Show more to reveal advanced settings such as User Agent, an Ignore robots.txt toggle, a JS Rendering toggle, a Crawl Speed slider, and URL Exclusion conditions. After making your changes, click Update, return to the three-dot menu, and click Recrawl to launch the new crawl with your updated settings. Use Recrawl whenever you want Search Atlas to refresh the audit for an existing site and reflect the latest version of your website. If you want even better results, review your Crawl Settings first so the next crawl runs with the exact scope and behavior you need. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🌐 Cloudflare Nameserver Changes, DNS Propagation & Downtime

🔎 Overview Switching your nameservers to Cloudflare is a common step for improving site performance and security. However, the transition involves DNS propagation — a process that can temporarily affect your site's availability. When you update your nameservers, you are instructing the internet to stop using your old DNS provider and route traffic through Cloudflare instead. DNS records are cached across thousands of servers worldwide, and each of those servers must individually receive and apply the update. This process cannot be skipped or manually accelerated. This article explains what is normal, what is not, and who is responsible for resolving each type of issue. ⏱️ How Long Does DNS Propagation Take? After you point your domain's nameservers to Cloudflare, DNS changes must spread across servers worldwide. Here is what to expect: - Typical range: 30 minutes to 48 hours, depending on your domain registrar and global DNS infrastructure. - Most cases: Propagation completes within 2–6 hours for the majority of visitors, though some visitors may not see the updated routing for up to 12 hours. - Full global propagation: Can take up to 72 hours in rare circumstances, particularly for older TTL (Time to Live) settings on your previous DNS records, or in certain geographic regions with slower ISPs. During propagation, some visitors may see your old site, some may see your new Cloudflare-routed site, and a small number may experience brief intermittent access. This inconsistency is expected and temporary. Eight hours of downtime is well within the normal propagation window and does not by itself indicate a configuration problem. 🚫 What Not to Do During Propagation Avoid making additional DNS changes while propagation is in progress. Each edit can reset the clock and extend your downtime. Specifically: - Do not switch nameservers back to your previous provider - Do not delete or modify DNS records in Cloudflare until propagation is confirmed complete - Do not contact your domain registrar to try to speed up the process — propagation speed is determined by global DNS infrastructure, not your registrar 🚨 When Is Downtime NOT Normal? An 8-hour complete outage after a Cloudflare nameserver switch is not a standard propagation symptom. Prolonged downtime of this kind almost always points to one of the following server-side or configuration issues — none of which are caused by or controlled by Search Atlas: - Origin server misconfiguration: Cloudflare proxies traffic to your origin server. If the origin server's IP address, SSL certificate, or firewall rules are not correctly configured to accept Cloudflare's traffic, the site will go down. - Missing or incorrect DNS records in Cloudflare: After switching nameservers, Cloudflare imports your existing DNS records automatically — but this import is not always complete. A missing A record, CNAME, or MX record can cause downtime. - SSL/TLS mode mismatch: If your Cloudflare SSL/TLS setting (e.g. Full, Full Strict, Flexible) does not match your hosting provider's SSL configuration, the connection between Cloudflare and your origin server will fail. - Hosting provider firewall blocking Cloudflare IPs: Some hosting providers block traffic from Cloudflare's IP ranges by default. You may need to whitelist Cloudflare's IP addresses with your host. - Cloudflare account or zone configuration errors: An incomplete Cloudflare zone setup, a paused zone, or incorrect page rules can prevent your site from loading. 🛠️ Steps to Diagnose and Resolve Extended Downtime 1. Check your DNS records inside Cloudflare. Log into your Cloudflare dashboard and navigate to DNS → Records. Confirm that your A record points to the correct origin server IP address and that all other critical records (CNAME, MX, TXT) are present. 2. Verify your SSL/TLS mode. Go to SSL/TLS → Overview in Cloudflare. Match this setting to what your hosting provider supports. If unsure, start with Full and only use Full (Strict) if your origin has a valid SSL certificate installed. 3. Pause Cloudflare temporarily to isolate the issue. In your Cloudflare dashboard, go to Overview and click Pause Cloudflare on Site. If your site comes back online immediately, the issue is a Cloudflare configuration problem. If it remains down, the problem is with your origin server or hosting provider. 4. Contact your hosting or server provider. If pausing Cloudflare does not restore the site, the outage is on the server side. Contact your hosting provider directly — they have access to server logs, firewall settings, and SSL configurations that are outside Cloudflare's and Search Atlas's control. 5. Check Cloudflare's status page. Visit cloudflarestatus.com to rule out a platform-wide Cloudflare incident affecting your region. 6. Use a DNS propagation checker. Tools such as dnschecker.org and whatsmydns.net let you see how your nameserver changes have spread globally. Enter your domain name, select the NS (Nameserver) record type, and review the results by region. When all locations display Cloudflare's assigned nameservers (for example, xxx.ns.cloudflare.com), propagation is complete. If most locations show your Cloudflare nameservers but the site is still down, propagation is complete and the issue is configuration-related, not propagation-related. 🏗️ Does This Affect Search Atlas or Website Studio? Search Atlas and Website Studio (accessible from the left sidebar under Website Studio) operate independently of your domain's nameserver configuration. Any error messages or toast notifications you see inside the Search Atlas platform relate to platform-specific actions — such as API connections, content generation, or project settings — and are not indicators of your Cloudflare or DNS status. If you see an error toast inside Search Atlas while also experiencing site downtime, these are two separate issues. Do not assume one caused the other. Address your DNS and hosting issues directly with Cloudflare and your hosting provider, then separately troubleshoot any Search Atlas-specific errors. Once propagation is confirmed complete, go to Left sidebar → Website Studio and confirm that your custom domain is still correctly connected to your project. In some cases, a domain re-verification step may be required inside the platform following a nameserver change. 📋 Quick Reference: Normal vs. Not Normal - Normal: Site intermittently accessible for some visitors during the first 2–12 hours after switching nameservers. - Normal: Full propagation taking 24–48 hours on average, up to 72 hours in rare cases or isolated regions. - Normal: Different visitors seeing different versions of your site during propagation. - Not normal: Complete, uninterrupted downtime lasting beyond 72 hours after switching nameservers. - Not normal: Site still down after DNS propagation checkers confirm your Cloudflare nameservers are fully propagated worldwide. - Not normal: Cloudflare's dashboard displaying a warning or error on your domain zone. - Not normal: Domain failing to resolve even when tested from multiple networks or devices after the 72-hour window. 🚨 When to Escalate Reach out for support if any of the following apply after 72 hours have passed: - Your site remains completely inaccessible - Propagation checker tools still show old nameservers across all regions - Cloudflare's dashboard displays a warning or error on your domain - Your domain fails to resolve even when tested from multiple networks or devices If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⚙️ Whitelist Search Atlas Crawler IPs in Your CDN or Firewall

If your site is protected by a CDN, firewall, or security service, Search Atlas crawlers may be blocked from accessing your website. When this happens, Site Audit and other crawling features may fail to collect data or report incomplete results. This article explains how to allow Search Atlas crawlers through your security layer. 🤔 Why This Happens Many Content Delivery Networks (CDNs), Web Application Firewalls (WAFs), and hosting security providers automatically block unknown bots or limit requests from crawler IP addresses. If Search Atlas crawler IPs are blocked, you may experience: - ❌ Site Audits that fail or never complete. - ❌ Missing crawl data. - ❌ Incomplete site health reports. - ❌ Pages not being discovered during scheduled crawls. ✅ Solution Allow all official Search Atlas crawler IP addresses in your CDN, firewall, or hosting provider. You can always find the most up-to-date IP list here: 👉 https://bots.searchatlas.com/ip_list.txt ⚠️ Important Do not manually maintain your own IP list. Always use the official Search Atlas list, as crawler IPs may be added or updated over time. ☁️ If You're Using Cloudflare Cloudflare makes this even easier. 1. Log in to your Cloudflare dashboard. 2. Open your website. 3. Navigate to your Bot Management or Security settings. 4. Select Search Atlas from the Verified Bots list. 5. Save your changes. 📘 If needed, refer to Cloudflare's documentation for additional information about Verified Bots. 🛡️ Other CDNs or Firewalls If you're using another provider (such as Akamai, Fastly, Imperva, Sucuri, AWS WAF, or another security platform): 1. Open your firewall or bot management settings. 2. Whitelist all IP addresses from the official Search Atlas IP list. 3. Save your configuration. 4. Run your Site Audit again. 🔍 Verify the Fix After updating your security settings: 1. Open Site Audit in Search Atlas. 2. Start a new crawl. 3. Wait for the crawl to begin. ✅ If the crawl starts successfully, your whitelist has been configured correctly. 🚨 Still Having Issues? If you've already whitelisted the official Search Atlas IP addresses but crawls are still failing: - ✔️ Verify that your CDN changes have fully propagated. - ✔️ Check whether another firewall, hosting provider, or security plugin is blocking requests. - ✔️ Confirm you're using the latest IP list from the official Search Atlas source. - ✔️ Contact Search Atlas Support if the issue persists. 📋 Quick Summary | ⚠️ Problem | Your CDN or firewall is blocking Search Atlas crawlers. | | --- | --- | | ✅ Solution | Whitelist the official Search Atlas crawler IPs or enable Search Atlas as a Verified Bot in Cloudflare. | | --- | --- | | 🔗 Official IP List | https://bots.searchatlas.com/ip_list.txt | | --- | --- |

🔄 How to Recrawl Your Website After a Site Migration

📋 Overview After completing a site migration—whether you changed domains, switched to HTTPS, restructured URLs, or moved platforms—your Search Atlas data may still reflect your old site. Running a fresh crawl ensures your audits, Site Explorer data, and on-page recommendations match your current website. This guide walks you through how to recrawl your entire site and what to do after the crawl finishes. 🕒 When You Should Recrawl Recrawl your website whenever you have made significant changes, including: - Migrating to a new domain or subdomain - Switching from HTTP to HTTPS - Changing your URL structure or permalinks - Moving to a new CMS or hosting platform - Publishing or removing large amounts of content ✅ Before You Start To get accurate results, confirm the following first: - Migration is complete. Wait until all redirects, DNS changes, and content updates are live. - The site is publicly accessible. Remove any password protection, staging restrictions, or "noindex" directives that should not be there. - Your robots.txt allows crawling. Make sure it does not block the pages you want analyzed. - The correct domain is set in your project. If you migrated to a new domain, you may need to add it as a new project (see below). 🔁 Recrawling Within the Same Domain If your site stayed on the same domain (for example, you only changed URL structures or content), you can recrawl your existing project: 1. Log in to your Search Atlas Home. 2. Open the Site Audit tool from the left-hand menu. 3. Select the project for your migrated website. 4. Click the Recrawl (or Crawl Now) button at the top of the audit page. 5. Confirm the crawl settings, including crawl depth and page limits, then start the crawl. The crawl runs in the background. Larger sites take longer, so allow time for it to finish before reviewing your results. 🌐 Recrawling After a Domain Change If you migrated to a brand-new domain, create a new project so your data is tied to the correct URL: 1. From your Search Atlas Home (Hi, CSM. What will we get done today?), click the Create Project button — or go to OTTO SEO → All Sites (OTTO SEO Projects) and click Create. 2. Enter your new domain exactly as it appears live (including HTTPS and www, if applicable). 3. Complete the project setup steps and connect any integrations, such as Google Search Console. 4. Open Site Audit for the new project and start your first crawl. Domain reprocessing for a migrated site now runs automatically once your project is set up—you no longer need to submit a manual request to our support team to have the domain recrawled. ⚙️ Adjusting Crawl Settings For larger or recently migrated sites, review these settings before crawling: - Page limit: Increase this if your site has more pages than the default allows, so the full site is captured. - Crawl depth: Set a depth that reaches deeper pages in your site structure. - Subdomains: Enable subdomain crawling if your content lives across multiple subdomains. 🏁 After the Crawl Finishes Once the crawl completes, take these steps to confirm everything migrated correctly: - Check the crawled page count. Compare it to your expected number of live pages. - Review redirects. Look for broken redirect chains or 404 errors from old URLs. - Scan for indexing issues. Confirm important pages are not blocked or marked "noindex." - Look at site health scores. Use the audit recommendations to fix any new issues introduced during migration. 🛠️ Troubleshooting 🔍 The crawl returns very few pages This usually means crawling is being blocked. Check your robots.txt file, remove any unintended "noindex" tags, and confirm the site is not behind a login or staging firewall. 🔗 Old URLs still appear in reports Historical data is retained for reference. After a fresh crawl, new reports reflect your current site. If you changed domains, make sure you are viewing the new project. 🤖 The AI agent says the recrawl finished, but results haven't updated If you triggered the recrawl through the in-app AI agent, confirm the crawl status directly in the Site Metrics tool rather than relying on the agent's confirmation. We are aware of an issue where the agent can report a recrawl as "completed" before it has actually verified the crawl's status. Treat the crawl status shown in Site Audit as the source of truth. ⏳ The crawl is taking a long time Large sites naturally take longer. Crawls run in the background, so you can leave the page and return later. If a crawl appears stuck for an unusually long time, contact our support team. 💬 Need More Help? If your results still look incorrect after recrawling, reach out to our support team through the in-app, typing "Human Teammate". Include your project name, your old and new domains, and the date of your migration so we can assist you quickly.

Understanding Optional Schema Warnings in Google Rich Results Tool

When validating structured data, you may encounter warnings about missing or invalid schema fields in Google Rich Results Tool. However, not all warnings indicate problems that require action. In some cases, Google Rich Results Tool may flag optional schema properties. These warnings are informational recommendations rather than validation errors and do not necessarily indicate issues with your schema implementation. Because Google Rich Results Tool and schema.org validator serve different purposes, it is possible for a page to pass schema.org validation while still displaying optional-field warnings in Google's tools. 🔍 Why Do Different Validation Tools Show Different Results? Google Rich Results Tool and schema.org validator serve different purposes and therefore may report different results. 🧩 schema.org Validator The schema.org validator checks your structured data against the official schema.org specification. If your markup complies with schema.org requirements, the validator will consider it valid—even if certain optional properties are not present. 🔎 Google Rich Results Tool Google Rich Results Tool focuses on Google's interpretation of structured data and may highlight additional fields that Google recommends but does not require. These recommendations often appear as warnings rather than errors. As a result, it is possible for structured data to: - Pass validation in schema.org validator - Display warnings in Google Rich Results Tool - Remain fully valid and functional 🏷️ A Common Example - mainEntityOfPage The presence of these kind of warnings does not automatically indicate a problem with your schema implementation. 🔑 Key Facts - ✅ schema.org validator is the authoritative reference for schema.org compliance - ✅ Optional fields are not required for valid schema implementation - ⚠️ Google Rich Results Tool may display recommendations for optional fields - ℹ️ Not every warning represents a technical issue that needs correction - 📈 Optional-field warnings are not ranking factors by themselves - ✅ Passing schema.org validation generally indicates your structured data is implemented correctly 🛠️ What Should You Do? When validating structured data: ✅ Recommended Approach 1. Use the schema.org validator as your primary validation source: - https://validator.schema.org/ 2. Review Google Rich Results Tool warnings and recommendations. 3. Prioritize fixing: - Missing required properties - Invalid values - Syntax errors - Structured data validation errors 4. Evaluate optional-field warnings individually rather than treating them as critical issues. 🎯 Important Reminder Warnings related to optional schema properties are generally informational and should not be treated the same way as validation errors. ✅ Conclusion OTTO and Search Atlas use schema.org as the primary source of truth for structured data validation. Google Rich Results Tool may display warnings for optional schema properties that are not required by schema.org. This behavior is expected and does not necessarily indicate a problem with your schema implementation. If your structured data passes schema.org validation and contains all required properties, optional-field warnings can generally be treated as recommendations rather than errors requiring action.

📘 Optimizing Articles for Technical SEO Using Quantum Newswire

📋 What You'll Learn This article walks you through how to maximize SEO impact using the Quantum Newswire platform, as demonstrated in a live training session with an agency. The walkthrough covers: - Best practices for internal and external linking in your articles - How to leverage Google Business Profile (GBP) post images to reinforce local relevance - How to add structured on-page signals to enhance indexing - How to use "People Also Ask" (PAA) questions to enrich topical depth and search intent 🎬 Watch the Training Video Watch a full training session where we demonstrate these strategies in real-time: ⚡ Quick Tips to Remember - Linking Strategy: Include contextual internal links to other relevant content. Use descriptive, relevant anchor text — avoid over-optimized exact-match anchor text, which can trigger spam signals. - On-Page Signals: Add schema markup (structured data) and bold key terms to aid crawler understanding and enable rich results in search. - GBP Images: Use branded images from Google Business Profile posts to strengthen local SEO signals. Note that geotagging image EXIF data is not a confirmed Google ranking factor for local SEO — focus instead on accurate GBP category, NAP consistency, and image file names. - People Also Ask: Pull real questions from Google's PAA boxes and answer them directly and concisely in your articles to improve topical depth and featured-snippet eligibility. 💡 Pro Tip Always include a mix of keyword-driven headings, embedded media, and FAQ sections to give Google rich, indexable content. Use structured data (e.g., FAQPage or Article schema) to help search engines surface your content in enhanced search 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.

Using Page Explorer for URL-Level Forensic SEO Analysis

Page Explorer is Search Atlas's URL-level forensic analysis tool, allowing SEO teams to investigate individual pages in depth and understand exactly how they fit into the technical and link architecture of a site. While site-wide audits surface trends, Page Explorer answers the question: what is happening at this specific URL, and why? What Page Explorer Shows You For every URL discovered during a crawl, Page Explorer provides a complete technical profile, including: - Indexability status — whether the page can be indexed by search engines - HTTPS and protocol resolution — confirming secure delivery - Status code validation — verifying 200, 301, 404, and other responses - Download and response time metrics — surfacing performance bottlenecks - Sitemap inclusion checks — confirming whether the URL is declared in XML sitemaps - Internal and external link analysis — mapping how the page connects to the rest of the web Incoming Internal Link Visibility One of Page Explorer's most powerful differentiators is incoming internal link visibility. Because Search Atlas performs a full site crawl, it can identify exactly which internal pages link to any given URL — a level of insight that is impossible without crawling the entire site. This makes it easy to: - Diagnose why low-value pages continue to receive authority - Understand how link equity flows through your site - Identify orphan pages with no internal links - Find opportunities to redirect or reroute internal links to higher-priority URLs Connecting First-Party Data When connected to first-party data sources, Page Explorer goes beyond technical metrics to surface business performance data: - Search Console performance — impressions, clicks, and queries - Click-through rates and positions — by URL - Analytics-based engagement and revenue signals — sessions, conversions, and revenue This enables teams to prioritize fixes based on technical impact and business value, not just crawl errors. A 404 on a high-revenue URL becomes a clear priority over a misconfigured tag archive with no traffic. How to Use Page Explorer Effectively 1. Run a site audit or open the Live Crawl Log 2. Click into any discovered URL to open Page Explorer 3. Review the technical signals to identify issues 4. Inspect incoming internal links to understand authority flow 5. Layer in Search Console and analytics data to prioritize remediation By combining full-site crawl data with first-party performance signals, Page Explorer turns individual URL diagnostics into a strategic prioritization tool.

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

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

🛠️ Moz Spam Score Increase and Domain Power Drop on a New Website

A rising Moz Spam Score and a Domain Power drop on a brand-new website are almost always caused by your backlink profile and limited site data, not by your content. This article explains what triggers both changes and walks you through auditing, disavowing spam links, and rebuilding authority. 🔎 What the Moz Spam Score Actually Measures Moz Spam Score is calculated entirely from your backlink profile — the external sites that link to you. It does not evaluate your on-page content, so minimal content changes will not move it. New websites frequently pick up automated spam links from low-quality or scraper sites within the first weeks of going live. When Moz crawls your domain and finds these links, it factors them in, which is why a score can jump from 1 to 55 in a single month. Outcome: You now know a high Spam Score reflects incoming links Moz flagged, not anything you wrote on your pages. 📊 Does a Moz Spam Score of 55 Hurt My Google Rankings? No. A Moz Spam Score of 55 does not directly affect your Google rankings. Moz is a third-party metric, and Google evaluates spam links independently — it discounts low-quality backlinks on its own rather than penalizing your site for receiving them. Treat the Spam Score as a health signal for your backlink profile, not as a ranking penalty. Outcome: You can address the score calmly as a cleanup task rather than an emergency. 🧹 How to Lower Your Moz Spam Score Follow these steps in order to clean up your backlink profile and bring the Spam Score down over time. Step 1: Run a Backlink Audit - Run a backlink audit to pull a full list of the domains linking to you. You can use a backlink explorer such as Moz Link Explorer to export the complete list of referring domains. - Identify the low-quality or spam links that are contributing to the elevated score. Step 2: Disavow Clear Spam Links - Review the flagged links and confirm which are clearly spam. - Disavow those spam links directly so search engines know to ignore them. Submit the list of spam domains through Google's Disavow Links tool in Google Search Console. Step 3: Build Quality Backlinks to Dilute the Ratio - Continue earning high-quality backlinks from reputable, relevant sites. - As legitimate links grow, the proportion of spam links shrinks, which lowers the Spam Score over time. Outcome: Your backlink profile becomes cleaner, and the Spam Score trends downward as quality links outnumber spam ones. 📉 Why Domain Power Dropped From 1 to 0 Domain Power is a Moz metric that reflects the overall authority of your domain, based largely on the quality and quantity of your backlink profile. A Domain Power drop from 1 to 0 is normal for a new website. New domains have very limited data, and the metric is subject to rounding artifacts at these low values, so it can read 0 even when nothing is wrong. Because Domain Power and Spam Score are both driven by your backlink profile, a wave of spam links can pull Domain Power down at the same time it pushes Spam Score up. The good news is that the cleanup steps above address both metrics at once: as you disavow spam links and earn quality backlinks, your Domain Power recovers alongside a falling Spam Score — so fixing one effectively helps fix the other. Domain Power becomes meaningful as a trend tracker once your site accumulates real authority through quality content and backlinks. Watch its direction over weeks and months rather than reacting to a single low reading. Outcome: You understand the 0 reading is expected early on and will rise as your site builds authority. 🎯 You now know that your Moz Spam Score reflects spammy incoming links rather than your content, that a score of 55 will not penalize your Google rankings, and that a new site's Domain Power of 0 is a normal early-stage artifact. Run a backlink audit, disavow clear spam links, and keep building quality backlinks to recover both metrics over time.

🔍 View Site Auditor How to Fix Details

🧭 Where Your Site Audit Lives All site audit data is accessed through the OTTO SEO section of Search Atlas. Start by navigating to Left sidebar → OTTO SEO → All Sites and clicking your project card. This opens your project's audit dashboard, where you can review crawl results and flagged issues across the Left sidebar → OTTO SEO → Site Audit → Overview (Website Overview) and Left sidebar → OTTO SEO → Site Audit → Page Explorer screens. 🐛 How to Find Your Flagged Issues The Left sidebar → OTTO SEO → Site Audit → Overview (Website Overview) screen is your starting point for reviewing all issues detected during the most recent crawl. Issues are grouped by severity into three categories: Errors, Warnings, and Notices. Each category lists every issue type found, together with the number of affected pages. ✅ How to Access 'How to Fix' Details The How to Fix guidance is not visible at the category level — you must click into a specific issue to reveal it. Follow these steps: 1. Go to Left sidebar → OTTO SEO → All Sites and open your project card. 2. Navigate to Left sidebar → OTTO SEO → Site Audit → Overview (Website Overview) to see the full issues list. 3. Expand the relevant severity category (Errors, Warnings, or Notices) if it is collapsed. 4. Click the specific issue name — for example, Missing Meta Descriptions or Broken Internal Links — not the category header. 5. A detail panel will open showing three sections: About (an explanation of the issue), How to Fix (step-by-step remediation instructions), and Affected Pages (every URL impacted). 6. Read the How to Fix section and work through the Affected Pages list to identify which URLs need to be updated. 📄 Investigating Issues by URL in Page Explorer If you prefer to see all issues on a specific page rather than all pages with a specific issue, use the Page Explorer. Navigate to Left sidebar → OTTO SEO → Site Audit → Page Explorer, search for or select the URL you want to inspect, and a full list of flagged issues for that page will appear. Clicking any issue in this view also surfaces its How to Fix guidance. ⚠️ Common Reasons 'How to Fix' Is Not Visible If the How to Fix section is not appearing, check the following: - You clicked a category header, not an individual issue. Expand the category and click the specific issue name underneath it to open the detail panel. - The crawl is still running. Issue details only fully populate after the crawl finishes. Check progress at Left sidebar → OTTO SEO → Site Audit → Crawl Monitoring and wait for the status to show as complete before reviewing results. - The issue shows zero affected pages. If no pages are impacted, there are no fix details to display — your site passes that particular check. - A stale browser cache. Perform a hard refresh with Ctrl + Shift + R (Windows) or Cmd + Shift + R (Mac), or open the platform in a private or incognito window. 🔄 Verifying Your Fixes After Making Changes Once you have applied the recommended fixes to your site, trigger a new crawl to confirm the issues are resolved. From Left sidebar → OTTO SEO → Site Audit → Overview (Website Overview), click the Re-crawl button. After the crawl finishes, return to the same issue and confirm the affected page count has dropped. You can monitor crawl progress in real time at Left sidebar → OTTO SEO → Site Audit → Crawl Monitoring. If you need further assistance, open 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 Is a robots.txt File and How to Fix Common Issues

What Is a robots.txt File? A robots.txt file is a plain text file placed at the root directory of a website that tells web crawlers which areas of the site they are allowed to access and which areas they should avoid. It contains a list of user-agent strings (the name of the bot), crawling directives, and the URL paths to which access is restricted. When you create a website, you may want to prevent search engines from indexing certain pages — such as thank-you pages, confirmation pages, staging content, or duplicate pages. The robots.txt file is where web crawlers learn what they can and cannot access. It is also the mechanism for blocking non-search-engine crawlers (such as those from third-party tools) from accessing your pages. Where Is the robots.txt File Located? The robots.txt file must be placed in the root directory of your website. For example, if your site is https://www.example.com, the file must be accessible at https://www.example.com/robots.txt. If a web crawler cannot find the robots.txt file at the root directory, it will assume no file exists and proceed to crawl all pages accessible via links on your site. How you upload the file depends on your website platform and server architecture — contact your hosting provider if you are unsure. Why Does robots.txt Matter for SEO? The robots.txt file is considered a fundamental part of technical SEO because search engines discover and understand websites entirely through their crawlers. The robots.txt file is the most direct way to communicate with those crawlers. Key benefits include: - Improved crawl efficiency by directing bots toward valuable content - Preventing low-value pages (e.g., confirmation pages, internal search results) from being indexed - Reducing the risk of duplicate content issues - Keeping unfinished or private content away from search results How Does robots.txt Work? When a search engine bot encounters a robots.txt file, it reads the file and follows the instructions. A basic entry looks like this: User-agent: googlebot Disallow: /confirmation-page/ This tells Googlebot not to crawl the /confirmation-page/ path or any URL within that subdirectory (e.g., /confirmation-page/order/, /confirmation-page/demo/). If a URL is not mentioned in the file, the crawler is free to access it as normal. It is important to note that robots.txt is a directive, not a security mechanism. Most reputable crawlers follow it, but it does not technically prevent access to pages — it is a convention, not a lock. Do not rely on it to protect sensitive data. Best Practices for robots.txt - The file must be a plain text file encoded in UTF-8 format - The filename is case sensitive — it must be named exactly robots.txt - Place the file at the root directory of your website or subdomain - Maintain only one robots.txt file per (sub)domain - You can only have one group of directives per user agent within the file - Be as specific as possible with disallow paths to avoid accidentally blocking entire sections of your site - Do not use the noindex directive inside robots.txt — this directive is not reliably supported there; use meta robots tags on individual pages instead - Remember that robots.txt is publicly visible — do not reveal the existence of confidential or sensitive sections of your site through it - robots.txt is not a substitute for configuring robots meta tags on individual pages; use both appropriately - Reference your XML sitemap within your robots.txt file, and ensure the sitemap is publicly accessible Common robots.txt Issues and How to Fix Them When a site's robots.txt file is misconfigured, it can negatively affect how search engines crawl and index your content. Search Atlas's Site Auditor can flag these issues automatically. Below are the most common problems and how to resolve them. 1. robots.txt File Not Present If you do not have a robots.txt file, or if it is not located at the correct root-level URL, crawlers will assume no restrictions exist and crawl your entire site. Resolution: Create a valid robots.txt file and upload it to the root directory of your website. 2. robots.txt Present on a Non-Canonical Domain Variant Best practice requires only one robots.txt file per canonical (sub)domain. If your robots.txt is located on a non-canonical variant of your domain (e.g., the non-www or HTTP version when the canonical is www/HTTPS), it may cause confusion for crawlers. For example, if your canonical domain is https://www.example.com, your robots.txt should be at https://www.example.com/robots.txt — not at http://example.com/robots.txt or https://example.com/robots.txt. Resolution: Move the file to the canonical domain location, or set up 301 redirects from non-canonical robots.txt URLs to the canonical version. 3. Invalid Directives or Syntax Including unsupported or incorrectly formatted directives means crawlers may ignore your instructions entirely and access pages you intended to block. Common syntax errors include misspelled directives, incorrect spacing, or using directives that are not part of the robots.txt standard. Resolution: Audit your robots.txt file carefully. Use only supported directives (User-agent, Disallow, Allow, Sitemap, Crawl-delay where supported). Validate your file using Google Search Console's robots.txt tester or a similar tool. 4. Sitemap Not Referenced or Not Accessible Best practice is to include a reference to your XML sitemap within your robots.txt file so crawlers can easily find it. If the sitemap is referenced but returns a 4xx or 5xx error, it can hinder crawling efficiency. Resolution: Add a Sitemap: directive pointing to your sitemap's full URL, and confirm the sitemap is publicly accessible and returns a 200 status code. 5. Crawl-Delay Directive Misuse Some implementations incorrectly include crawl delay settings that are either unsupported by major search engines (Googlebot does not support Crawl-delay) or set too aggressively, which can slow down beneficial crawling. Resolution: Use Google Search Console to manage Googlebot's crawl rate instead of relying on the Crawl-delay directive. Remove the directive if it is causing issues with major search engine bots. Using Search Atlas to Identify robots.txt Issues Search Atlas's Site Auditor can automatically detect robots.txt problems as part of a full technical SEO audit — including missing files, non-canonical placement, invalid syntax, inaccessible sitemaps, and problematic directives. OTTO SEO can also assist with ongoing technical SEO monitoring to help keep your site's crawlability in good standing. If you need further assistance, open the 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 Blocking and Understand Crawl Scheduling

🗺️ Overview Search Atlas uses its own crawler to audit your site independently of Google. This means two separate processes are at work: the Search Atlas crawler (which powers your site audit data inside the platform) and Google's crawler (which determines your rankings). Understanding the difference — and making sure Search Atlas can actually access your pages — is the first step to accurate audit results. ⏱️ When Do Search Atlas Results Update After Site Changes? Search Atlas does not update automatically the moment you publish changes. Here is how the process works: 1. You trigger or schedule a crawl. Navigate to your site audit dashboard inside the platform and start a fresh crawl manually using the crawl option available there. 2. The Search Atlas crawler visits your pages. Depending on your site size, this can take a few minutes to several hours. 3. Your audit data refreshes. Once the crawl completes, all metrics — broken links, missing tags, page speed issues — reflect the current state of your site. This process is entirely separate from Google. Even after Google re-indexes your updated pages, your Search Atlas audit data will only reflect those changes after a new Search Atlas crawl is run. 🚫 Why Is the Search Atlas Crawler Being Blocked? If you see an error message indicating the crawler is blocked, it means your site's robots.txt file is preventing Search Atlas from accessing your pages. This is one of the most common reasons audit data appears incomplete or stale. A blocked crawler cannot collect data — regardless of what the platform status shows. Do not assume your site is configured correctly if you have received a blocking error. The error message is definitive. Follow the steps below to diagnose and fix the issue. 🔎 How to Check Your robots.txt File Your robots.txt file lives at the root of your domain. To view it, type the following into your browser address bar, replacing the example with your own domain: https://yourdomain.com/robots.txt Look for any lines that contain Disallow rules that could block the Search Atlas crawler. A blocking rule would look like one of these: - User-agent: * followed by Disallow: / — this blocks all crawlers, including Search Atlas. - A user-agent entry for the Search Atlas crawler followed by Disallow: / — this blocks Search Atlas specifically. - Disallow: / appearing under a wildcard rule with no corresponding Allow exception for the Search Atlas crawler. 🛠️ Fixing robots.txt Blocking on WordPress On WordPress, your robots.txt rules are often controlled by an SEO or security plugin rather than a static file. Follow these steps to locate and resolve the blocking rule: 1. Check your SEO plugin settings. If you use a plugin such as Yoast SEO or Rank Math, navigate to its settings in your WordPress admin dashboard and look for a robots.txt editor. Review any Disallow rules and remove or adjust any rule that blocks all bots or specifically blocks the Search Atlas crawler. 2. Check your security plugin settings. Security plugins such as Wordfence include bot-blocking features that can prevent crawlers from accessing your site. In the plugin's settings, review any bot or crawler blocking rules and add an exception to allow the Search Atlas crawler through. 3. Check for maintenance mode. If your site is in maintenance mode (via a plugin or theme setting), all external crawlers will typically be blocked. Disable maintenance mode and re-check your robots.txt file. 4. Verify the fix. After making changes, revisit https://yourdomain.com/robots.txt in your browser to confirm the blocking rule has been removed. Then return to the Search Atlas platform and trigger a new crawl from your site audit dashboard so the crawler can re-access your pages. 5. Confirm audit data updates. Once the new crawl completes, verify that your site audit data is now populating correctly. If the crawler-blocked error persists after following these steps, note your domain, the exact error message shown in the platform, and which plugin(s) you checked so our team can assist you efficiently. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🖼️ Why Your Search Preview Logo Still Shows the Old Image

🤔 The Common Mix-Up A frequent question we hear is: "I updated my logo in Search Atlas Brand Vault, but search previews still show the old logo. I've cleared every cache layer and it won't update." If this sounds familiar, the good news is that nothing is broken. The issue is simply that two different features are being confused. Brand Vault and Open Graph serve completely different purposes, and only one of them affects what appears in search and social previews. 🎨 What Brand Vault Actually Does Brand Vault is an internal Search Atlas feature. It stores your brand assets so they appear consistently inside the platform and in the reports and documents you generate. - White-label reports that display your logo instead of ours. - Exported PDFs and dashboards shared with clients. - Consistent branding across the tools you use day to day. Behind the scenes, Brand Vault also feeds Search Atlas's internal Knowledge Graph, which supplies your brand information to AI-powered tools such as OTTO and Content Genius. Note that this internal Knowledge Graph is not Google's Knowledge Graph or Knowledge Panel — despite the similar name, the Search Atlas version lives entirely inside the platform. Brand Vault never edits your live website's code. Because of this, it has no influence over how your site appears in Google search results, link previews, or social media cards. 🌐 What Controls Search and Social Previews The logo or image shown when your page appears in search results or is shared on social platforms is controlled by Open Graph tags and related metadata in your website's HTML. The key tags include: - og:image — the image used for social and link previews. - og:title and og:description — the text shown alongside the image. - Structured data (schema) logo — the logo Google may use in certain search features, such as the Knowledge Panel. - Favicon — the small icon shown next to some search listings. These tags live on your actual website, not inside Search Atlas. Updating Brand Vault will not change them. To update your search preview logo, you must update the metadata on your live site. 🛠️ How to Update Your Search Preview Logo Follow these steps to correct an outdated preview image: 1. Locate the Open Graph tags on your website. These are usually in the page header, managed through your CMS, theme settings, or an SEO plugin. 2. Update the og:image URL to point to your new logo. Make sure the image meets recommended dimensions (at least 1200 x 630 pixels works well for most platforms). 3. Update your structured data logo if your site uses organization schema, so Google references the correct image. 4. Replace your favicon if the small search icon also needs updating. 5. Publish the changes and confirm the new image loads when you view your page's source code. ♻️ Why Clearing Cache Isn't Enough Clearing your website and browser cache is a good habit, but it does not solve this issue on its own. Search engines and social platforms keep their own separate cache of your page metadata. Even after your site is updated, the old image can linger until those external systems refresh. To speed this up: - Use the platform's sharing debugger or validation tools (offered by major search and social networks) to force a re-fetch of your updated metadata. - Request re-indexing of the affected page through your search engine's webmaster tools. - Allow time for search engines to recrawl, which can take anywhere from a few days to a few weeks. ✅ Quick Reference - Logo wrong in Search Atlas reports? Update Brand Vault. - Logo wrong in search or social previews? Update the Open Graph tags and metadata on your website, then trigger a re-fetch. - Still seeing the old image? Give external caches time to refresh and confirm the new image URL loads correctly.

🖼️ SVG Image Alt Text in Onpage Audit

🔍 Overview When running an Onpage Audit in Search Atlas, you may notice tasks flagging images that ask you to add alt text — but the images appear to be SVG files. This article explains why this happens, what Search Atlas currently supports, and what steps you should take to protect your SEO. ⚠️ Known Limitation: No Alt Text Suggestions for SVG Images Search Atlas does not generate alt text suggestions for SVG (Scalable Vector Graphics) images. This is a current product limitation. When the Onpage Audit detects an SVG image that is missing an alt attribute, it will still flag the image as an issue — but it will not provide a recommended alt text value the way it does for standard raster images (JPEG, PNG, WebP, etc.). This means if you see an alt text task referencing an SVG file, you will need to write the alt text yourself and apply it directly in your website's code or CMS. 📋 How to Identify SVG Image Tasks in Your Audit 1. Navigate to your Onpage Audit report inside Search Atlas. 2. Locate the Image Alt Text issue section. 3. Review the flagged image URLs. SVG files will have a .svg file extension in their URL path (for example, logo.svg or icon-arrow.svg). 4. These tasks will not include a pre-filled alt text suggestion. You will need to provide the value manually. ✍️ What Alt Text Should You Write for SVG Images? Even though Search Atlas does not generate suggestions for SVGs, writing good alt text for them follows the same SEO best practices as any other image. Use the guidance below: - Describe the image's purpose, not just its appearance. Ask yourself: what would a visitor miss if this image did not load? Answer that question in plain language. - Be concise. Aim for one short sentence — typically under 125 characters. - Include a relevant keyword naturally if it fits the context. Never force keywords or stuff the alt attribute. - If the SVG is purely decorative (such as a background shape or divider line), use an empty alt attribute (alt=""). This tells screen readers to skip it and prevents unnecessary noise for assistive technology users. - If the SVG is a logo, include the brand name and the word "logo" — for example, Search Atlas logo. - If the SVG is an icon with a functional purpose (such as a search or menu icon), describe its action — for example, Open navigation menu. 📉 Will Missing SVG Alt Text Hurt My SEO? Yes, it can — depending on how the SVG is used on the page. Here is what you need to know: - Search engines index alt text as part of image and page relevance signals. SVG images embedded directly in HTML (inline SVGs) or referenced via an <img> tag without alt text represent a missed optimisation opportunity. - Accessibility is a ranking consideration. Google's guidance aligns helpful alt text with better page quality signals. Pages with missing alt text on meaningful images may rank lower in image search and can receive lower Core Web Vitals accessibility scores. - The impact varies by context. A missing alt attribute on a decorative SVG icon is unlikely to cause a significant SEO drop. A missing alt attribute on an SVG infographic or hero image that communicates key page content is a more meaningful gap to fix. - Resolving the task in the Onpage Audit after you have manually added alt text will require you to re-crawl the page so Search Atlas can verify the fix. Use the Re-crawl option within the audit to update the task status. ✅ Recommended Workflow for SVG Alt Text Tasks 1. Open your Onpage Audit and filter for Image Alt Text issues. 2. Identify which flagged images are SVG files by checking the file extension in the image URL. 3. For each SVG, decide whether it is meaningful (needs descriptive alt text) or decorative (needs an empty alt attribute). 4. Write your alt text following the best-practice guidelines above. 5. Apply the alt attribute in your CMS, page builder, or directly in your site's HTML. 6. Return to the Onpage Audit and trigger a re-crawl of the affected page to confirm the issue is resolved. 🛠️ What Search Atlas Is Working On SVG alt text suggestion support is a known gap in the current version of the Onpage Audit. Our product team is aware of this limitation and it is under review for a future update. When this capability becomes available, you will be able to receive AI-generated alt text suggestions for SVG images the same way you do for standard image formats. 💬 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.

📊 Why Site Lens and Page Explorer Show Different Page Counts

Site Lens and Page Explorer pull their page totals from different data scopes within the same Site Audit crawl. Site Lens counts only pages it can place in the link-depth visualization; Page Explorer counts every crawled URL, so the two numbers will not always match. 📊 What Site Lens Counts Site Lens builds a link-depth chart showing how many pages sit at each click-depth from your homepage. To populate that chart, it draws only from pages that have a confirmed link-depth value — pages reachable via at least one measured internal link path from the homepage. Pages the crawler visited but could not assign a depth position to are excluded from the Site Lens total. As a result, the Total pages figure in Site Lens reflects the visualization scope, not the full crawl. 🔍 What Page Explorer Counts Page Explorer reports against the complete crawl dataset. Every URL the crawler visited — regardless of whether it has a calculable link-depth value — is counted and listed here. Page Explorer is the authoritative source for your site's total crawled page count and the right tool for auditing full crawl coverage. ⚠️ Why Orphaned Page Counts Also Differ Orphaned pages are URLs the crawler found (typically through a sitemap or external backlink) that have no internal links pointing to them. Because they have no inbound internal link path, they also have no calculable link depth, so Site Lens cannot place them in its depth chart. Site Lens counts only the orphaned pages it can position in the depth structure. Page Explorer counts all orphaned pages across the full crawl. The two orphaned-page totals will differ whenever your site has orphaned pages — which is the common case. 💡 When to Use Site Lens vs. Page Explorer - Analyzing link depth and site architecture — use Site Lens. Its counts correctly reflect how pages are distributed across depth levels and how well your internal linking reaches every section of the site. - Auditing total crawled pages or finding all orphaned pages — use Page Explorer. It covers the full crawl and is the reliable source for SEO coverage checks and orphan-remediation workflows. 🎯 Site Lens is built for depth-structure analysis; Page Explorer covers your complete crawl. Use Page Explorer as your source of truth for total and orphaned page counts, then switch to Site Lens to understand and improve how those pages are reached through internal linking.

🔍 Fix 'How to Fix' Details Not Showing in Site Auditor

🧭 Overview When the Site Auditor flags issues in your web report, the Issues or Page Explorer tab should display a How to Fix section for each problem. If that section is blank, the button is missing, or instructions never appear, a few specific conditions may be responsible. This article walks you through every known cause and the steps to resolve them. 🔎 Why 'How to Fix' Details May Not Appear There are four distinct reasons this content can be missing. Work through each one before contacting support. 🖥️ Reason 1 — Browser Zoom Is Not Set to 100% The How to Fix button is only rendered correctly when your browser zoom level is exactly 100%. At any other zoom level the button may be clipped, pushed off-screen, or hidden entirely. 1. In your browser, press Ctrl + 0 (Windows) or Cmd + 0 (Mac) to reset zoom to 100%. 2. Alternatively, open your browser menu, locate the zoom control, and manually set it to 100%. 3. Reload the Site Auditor page and re-open the issue detail panel. 4. Confirm the How to Fix button is now visible before proceeding. ⚙️ Reason 2 — JavaScript Rendering Is Disabled Fix details are loaded dynamically. If JavaScript rendering is blocked or disabled in your browser, the content will never populate — even if the button appears. 1. Open your browser settings and search for JavaScript or Site settings. 2. Ensure JavaScript is set to Allowed for the Search Atlas platform. 3. Disable any browser extensions that block scripts (ad blockers, script blockers) temporarily and reload the page. 4. If you use a corporate firewall or proxy, confirm it does not strip JavaScript responses from the platform domain. 🌐 Reason 3 — The Issue Is External or Requires a Manual Fix Not every flagged issue has an in-platform fix. Some problems exist on third-party services, your hosting environment, or your CMS — and the auditor correctly flags them without being able to resolve them automatically. In these cases the How to Fix section will either be absent or will show a short manual guidance note. Common examples include: - Missing or misconfigured robots.txt or sitemap.xml files hosted on your server. - Slow server response times (TTFB) controlled by your hosting provider. - Third-party scripts causing render-blocking issues. - Broken backlinks pointing to removed pages on external domains. For these issues, use the flagged URL and error description shown in the Page Explorer to locate and fix the problem directly in your CMS, hosting dashboard, or with your developer. 🔒 Reason 4 — Downstream Crawler Blockers Are Preventing Full Issue Analysis Some issues only surface completely after the crawler has full access to your site. If any of the conditions below apply, the audit may be incomplete and fix details may be partially or fully missing. - Mixed-content HTTP images: Pages that load images over HTTP instead of HTTPS can cause the crawler to fail mid-audit, including blocking sitemap reads. Ensure all image URLs in your HTML and CMS use HTTPS. - Crawler not whitelisted: If your site has bot protection (Cloudflare, Sucuri, password protection, or a WAF), the Search Atlas crawler user-agent may be blocked. Add the Search Atlas crawler IP or user-agent to your allowlist. Contact support via the chat widget for the current crawler details. - Crawl quota exceeded: Large sites may hit the crawl page limit included in your plan. When the quota is reached, pages beyond the limit are not analysed and their fix details will not be generated. Check your current plan limits and consider upgrading or narrowing the crawl scope in your audit settings. ✅ Quick Checklist Before Escalating - Browser zoom is set to exactly 100%. - JavaScript is enabled and no script-blocking extensions are active. - You have confirmed whether the issue is external or requires a manual fix. - Your site does not serve mixed-content (HTTP) images. - The Search Atlas crawler user-agent is whitelisted on any bot-protection layer. - Your crawl quota has not been exceeded for this audit. 🔄 How to Re-Run the Audit After Fixing Issues 1. Apply your fixes in your CMS, server, or hosting dashboard. 2. In Search Atlas, navigate to Site Metrics in the left sidebar. 3. Select your property and open the Site Auditor report. 4. Click Re-crawl or Start New Audit to generate a fresh report. 5. Once the audit completes, return to the Issues or Page Explorer tab to confirm the flags have cleared and How to Fix details load correctly. 💬 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.

🛠️ Stop Unwanted Schema Markup Deploying on Your Site

🔍 Why Schema Markup May Still Appear After Undeploying OTTO If you have undeployed all OTTO schema recommendations but schema markup is still being served on your website, the markup is likely coming from a source outside of OTTO's controls. Common sources include your WordPress theme or plugins and Custom HTML tags inside a Google Tag Manager (GTM) container. Both sources operate independently of OTTO's deploy/undeploy controls, so undeploying OTTO alone will not remove them. 📋 Source 1 — WordPress Theme or Plugin Injecting Schema Many WordPress themes and SEO plugins (such as Yoast SEO, Rank Math, or All in One SEO) output schema markup automatically. This markup will continue to appear on your site regardless of what you do inside Search Atlas. 1. View the source code of an affected page in your browser and search for <script type="application/ld+json"> to locate schema blocks. 2. Identify which plugin or theme is responsible — the surrounding code comments or script attributes often indicate the source. 3. Log in to your WordPress admin dashboard. 4. If a plugin is the source, navigate to that plugin's settings and look for a schema or structured data section where output can be disabled. 5. If your theme is the source, check your theme's settings or consult your theme documentation for how to disable built-in schema output. 6. Save your changes, then re-check the page source to confirm the schema blocks have been removed. In some cases schema output is hardcoded into a theme's template files. If no settings toggle is available, you may need to edit the theme files directly or use a child theme to override the output — or contact your theme developer for guidance. ⚙️ Source 2 — Google Tag Manager Container Injecting Schema A GTM container can inject schema markup site-wide through Custom HTML tags, entirely outside of Search Atlas. If your site uses GTM, your container may contain one or more Custom HTML tags that output schema JSON-LD or other structured data. 1. Log in to your Google Tag Manager account at tagmanager.google.com. 2. Open the container associated with your website. 3. Navigate to Tags and filter or scan for any tags of the type Custom HTML. 4. Open each Custom HTML tag and review its contents for schema markup (look for <script type="application/ld+json"> blocks). 5. For each tag containing unwanted schema, either pause or delete the tag depending on whether you may need it later. 6. Publish a new version of your GTM container to push the changes live. After publishing, allow a few minutes for the changes to propagate, then re-check your pages using a structured data testing tool to confirm the schema is no longer being served. ✅ How to Confirm the Schema Has Been Removed After completing the steps above, verify that no unwanted schema remains on your pages by using a structured data testing tool such as Google's Rich Results Test or Schema Markup Validator. If schema markup continues to appear and you cannot identify the source, please reach out to our support team via the chat icon in your Search Atlas dashboard and we will help you track it down.

🔍 Fix Hidden H1, Open Graph, and Alt Text Issues

🧭 Overview When Search Atlas audits your website, it flags on-page issues that can quietly hurt your search rankings. Three of the most common — hidden H1 tags, missing Open Graph tags, and missing image alt text — are easy to misunderstand but straightforward to fix. This article explains what each issue means, why it matters, and how to resolve it. 🔄 How to Run a New Site Analysis Before reviewing any issues, make sure your audit data is up to date. Follow these steps to run a fresh analysis: 1. Log in to Search Atlas and open the Site Auditor from the left-hand navigation. 2. Select the project you want to audit, or add a new one by entering your domain. 3. Click Run New Analysis in the top-right corner of the dashboard. 4. Wait for the crawl to complete — this typically takes a few minutes depending on site size. 5. Once finished, your updated results will appear automatically in the Issues tab. Re-running an analysis after making fixes is the best way to confirm that issues have been resolved. 🏷️ What Is a Hidden H1 Tag — and Is It Good for SEO? An H1 tag is the main heading on a webpage. Search engines treat it as a strong signal for what the page is about. A hidden H1 means the tag exists in the page's HTML code but is not visible to users — for example, it may be styled with display: none, visibility: hidden, or positioned off-screen. Is a hidden H1 effective for SEO? No — and it can be harmful. Here is why: - Google's guidelines discourage hiding content from users while serving it to search engines. This is considered a deceptive practice and can trigger a manual penalty. - If users cannot see your H1, it does not help them understand your page, which can increase bounce rates. - A visible, well-written H1 reinforces your page's topic for both users and search engines. To fix this issue, make your H1 tag fully visible on the page. Update its CSS so it is displayed normally and positioned within the page content. Every page should have exactly one visible H1 that clearly describes the page topic. 📣 What Are Open Graph Tags and Why Do They Matter? Open Graph (OG) tags are snippets of code placed in your page's <head> section. They control how your content appears when shared on social media platforms like Facebook, LinkedIn, and X (formerly Twitter). When Open Graph tags are missing, social platforms will attempt to guess the title, description, and image for your page — often with poor results. This can lead to unappealing link previews that reduce click-through rates from social media. The most important Open Graph tags to add are: - og:title — The title of the page as it should appear in a share preview. - og:description — A short summary of the page content (recommended: 150–160 characters). - og:image — A URL to the image that should appear in the preview (recommended size: 1200 × 630 pixels). - og:url — The canonical URL of the page. To fix missing Open Graph tags, add them to the <head> section of each affected page. If you use WordPress, plugins such as Yoast SEO or Rank Math can add these tags automatically. On other platforms, consult your theme or developer documentation for how to add custom meta tags. 🖼️ What Is Missing Image Alt Text and How Do I Fix It? Alt text (alternative text) is a short written description added to an image's HTML tag using the alt attribute. For example: <img src="team-photo.jpg" alt="Search Atlas team at the 2024 conference">. Missing alt text matters for two key reasons: - Accessibility: Screen readers used by visually impaired users rely on alt text to describe images. Missing alt text makes your site harder to use for these visitors. - SEO: Search engines cannot see images — they read alt text to understand what an image shows. Descriptive alt text helps your images appear in Google Image Search and reinforces your page's topic. To fix missing alt text: 1. In Search Atlas, go to the Issues tab and filter by Missing Alt Text to see all affected images. 2. Click on any flagged URL to see which images are missing alt text on that page. 3. Open your CMS (for example, WordPress Media Library) and add a concise, descriptive alt text to each image. 4. Avoid keyword stuffing — write naturally, as if describing the image to someone who cannot see it. 5. Leave the alt attribute empty (alt="") only for purely decorative images that add no informational value. ✅ Quick Summary - Hidden H1: Make it visible — hiding headings from users violates Google's guidelines and can trigger penalties. - Open Graph tags: Add og:title, og:description, og:image, and og:url to every key page to control how your content looks on social media. - Missing alt text: Write clear, descriptive alt text for all informational images to improve both SEO and accessibility. - Re-run your audit after making fixes to confirm the issues are resolved. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🗺️ Managing Sitemap URL Exclusions in Search Atlas

Overview When migrating from Yoast SEO to Search Atlas, you may notice that URL types you previously excluded from your sitemap — such as author pages, video pages, category pages, and tag pages — appear re-enabled in Search Atlas. This happens because Search Atlas maintains its own independent sitemap settings, and Yoast's exclusion rules do not carry over automatically. This article explains the current sitemap exclusion options available in Search Atlas, how they compare to Yoast, and what steps you can take right now to manage your sitemap effectively. How Search Atlas Sitemap Settings Work Search Atlas generates your sitemap automatically based on your site's content. You can access your sitemap settings inside the Search Atlas platform to view which URLs are currently included and make adjustments. It is important to understand that Search Atlas and Yoast approach sitemap configuration differently: - Yoast SEO allows you to disable entire URL types globally — for example, turning off all author archives, all tag pages, or all category pages with a single toggle. - Search Atlas currently focuses on URL-level and page-level controls rather than broad post-type or taxonomy-level exclusions. These controls are accessible in your WordPress admin panel under Search Atlas → Settings, where you can find options to include or exclude individual URL types such as post types and taxonomies. This means that after migrating, URL types that were globally suppressed in Yoast will not automatically carry over as excluded in Search Atlas. When you install Search Atlas and disable or remove Yoast, Search Atlas generates a fresh sitemap based on its own default settings — not Yoast's saved preferences. Those pages may reappear in your sitemap and, in some cases, surface with crawl errors, particularly if those pages return non-200 status codes or have other issues. What You Can Do Right Now While bulk post-type exclusion toggles are not yet available as a self-serve feature, there are practical steps you can take to reduce unwanted URLs in your sitemap: 1. Audit your sitemap errors: Log in to Search Atlas and navigate to your sitemap settings. Review any URLs flagged with errors and prioritise fixing or removing pages that should not be indexed. 2. Use noindex on unwanted page types: For author pages, tag archives, or category pages you do not want indexed, apply a noindex meta directive to those templates. Search Atlas respects noindex signals, so these pages will not pass SEO value. 3. Remove individual URLs: Where a specific URL is causing errors and should not appear in the sitemap, check whether your sitemap settings allow you to exclude it at the individual URL level. 4. Check your WordPress settings: For category, tag, and author archives, WordPress itself offers visibility controls. Setting these archives to noindex at the WordPress level helps ensure Search Atlas does not treat them as indexable pages. If you are unsure which steps apply to your setup or need help confirming what sitemap controls are available in your account, reaching out to the support team is the fastest way to get accurate guidance for your specific configuration. When you do, please have the following ready: - Your site URL - The specific URL types you want to exclude (e.g. author pages, category pages, tag pages, video pages) - The Search Atlas plugin version you have installed - A note of any crawl errors you are seeing related to the excluded URL types Yoast vs. Search Atlas: Feature Comparison - Global post-type exclusion toggle: Available in Yoast — not yet available as a self-serve option in Search Atlas. - Individual URL exclusion: Available in Search Atlas at the page level. - Noindex support: Respected by both Yoast and Search Atlas. - Automatic sitemap generation: Both tools generate sitemaps automatically based on your site's content. Recommended Settings After Migrating From Yoast To replicate your previous Yoast exclusions as closely as possible, review each of the following URL types and disable any that you had turned off in Yoast: - Author archive pages — commonly disabled on single-author sites to avoid duplicate content. - Category and tag archive pages — often excluded when they hold thin or duplicate content. - Video sitemaps — disable if you do not host video content or use a dedicated video sitemap plugin. - Custom post types — exclude any custom post types that should not be indexed or surfaced in search. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Title Tag Changes Not Showing on Google

🧭 Overview After deploying a title tag change, it is completely normal for the update to not appear immediately in Google's search results. This delay is caused by how Google crawls, processes, and caches web pages — not by a problem with your website or Search Atlas. This article explains why the delay happens and what steps you can take to encourage faster indexing. ⏱️ Why the Delay Happens When you update a title tag and deploy it to your live site, Google does not instantly detect the change. Here is what happens behind the scenes: - Crawl scheduling: Googlebot visits pages on its own schedule, which varies based on your site's crawl budget, authority, and how frequently it typically updates. - Processing and indexing: After Googlebot crawls the updated page, it must process the new content and update its index. This takes additional time. - Cache refresh: Even after the index is updated, Google's Search Engine Results Pages (SERPs) may still display a cached version of the old title for a short period. - Google's own rewriting: Google sometimes rewrites title tags to better match a user's search query. If you see a different title than what you set, Google may have overridden your tag — this is separate from indexing latency. In most cases, title tag updates are reflected in Google search results within a few days to a few weeks. For high-authority or frequently crawled sites, this can happen within 24–48 hours. For newer or lower-traffic sites, it may take longer. ✅ Steps to Encourage Faster Indexing While you cannot force Google to index your changes immediately, the following steps can help speed up the process: 1. Verify the change is live on your website. Before troubleshooting further, confirm that the updated title tag is actually present in your page's HTML. Right-click the page in your browser, select View Page Source, and search for the <title> tag. Make sure the new title appears there. 2. Submit the URL for indexing via Google Search Console. Open Google Search Console, paste your page URL into the top search bar, and click Request Indexing. This signals to Google that the page has been updated and should be recrawled. Note that this is a request, not a guarantee, and Google may take additional time to process it. 3. Check for crawl errors. In Google Search Console, review the Coverage or Pages report to ensure your page is not blocked by a noindex tag, robots.txt rule, or crawl error that would prevent Googlebot from seeing the update. 4. Ensure your sitemap is up to date. An updated XML sitemap helps Googlebot discover changed pages faster. Resubmit your sitemap in Google Search Console under Sitemaps if needed. 5. Build or refresh internal links to the page. Pages with more internal links tend to be crawled more frequently. Linking to the updated page from other active pages on your site can help Googlebot find it sooner. 📊 Monitoring Your Rankings in Search Atlas While waiting for Google to reflect your title tag change, you can monitor your page's ranking performance directly inside Search Atlas: - Go to Left sidebar → Keywords → Rank Tracker to track keyword positions for the page you updated. Rankings may shift as Google re-evaluates the page with the new title. - Use Left sidebar → Keywords → Keyword Magic to identify whether your new title tag is better aligned with the keywords your target audience is searching for. - Use Left sidebar → Keywords → Keyword Gap to compare your keyword coverage against competitors and validate that your title tag strategy supports your broader SEO goals. ⚠️ When to Be Concerned In most situations, waiting is the right approach. However, consider investigating further if: - More than 4 weeks have passed and the updated title still has not appeared in search results. - Google Search Console shows the page is not indexed or has a coverage error. - The title showing in the SERP is completely unrelated to either your old or new title tag — this may indicate a deeper on-page or structured data issue. 💡 Key Takeaways - Title tag changes are not reflected in Google search results instantly — this is normal and expected. - The typical timeframe is a few days to a few weeks depending on your site's crawl frequency. - Use Google Search Console's Request Indexing tool to signal your update to Google. - Search Atlas's Rank Tracker and Keyword tools can help you monitor ranking impact once the change is indexed. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Canonical URL Errors and Global Blog Styling

🎨 Setting Up a Consistent Look and Feel Across All Blogs Search Atlas does not currently have a single built-in "global blog template" feature that automatically applies one design to every blog. However, you can achieve a consistent look and feel across all your blogs using the workarounds below. 📋 Option 1: Use Brand Vault as Your Style Reference Brand Vault stores your brand assets — logos, color palettes, and font choices — so you can apply them consistently when building or editing each blog. 1. Access Brand Vault: top-right More Features menu (grid icon, next to your Avatar Menu (👤)) → Brand Vault, or Header More Features menu (apps-grid icon, top-right) → Brand Vault. 2. Confirm your brand colors, fonts, and logo are saved. 3. When creating or editing a blog in Website Studio, open the Brand Vault panel and apply your saved brand assets to match your desired style. 4. Repeat this process for each blog to keep styling consistent. Limitation: Brand Vault does not push styles automatically. You must apply your brand assets manually to each individual blog. 🖌️ Option 2: Apply Custom CSS to Each Blog If you need more precise control over the visual appearance, you can add custom CSS directly to each blog. 1. Open the blog you want to style in Website Studio. 2. Go to Settings within the blog editor. 3. Locate the Custom CSS field. 4. Paste your CSS rules. Use the same CSS code for every blog to keep the look consistent. 5. Save and preview to confirm the styles are applied correctly. Tip: Keep a copy of your CSS snippet in a text file so you can paste it quickly into each blog without re-writing it. 📄 Option 3: Duplicate an Existing Blog as a Starting Point 1. Build and style one blog to your exact specifications. 2. Use the Duplicate option on that blog to create a copy. 3. Rename the duplicate and update its content. 4. Repeat for each additional blog you need. This is the fastest way to maintain a uniform design when creating multiple new blogs from scratch. 🔍 Understanding the "11 Pages Have Multiple Canonical URLs" Error A canonical URL tells search engines which version of a page is the primary one. When Search Atlas detects that 11 pages each have more than one canonical URL defined, it flags this as an error because conflicting canonical signals can confuse search engines and hurt your rankings. ⚠️ Common Causes of Multiple Canonical URL Errors - Duplicate canonical tags in the page source: A canonical tag exists in both the <head> section and an HTTP response header, creating two competing signals. - Pagination misconfiguration: Paginated content (page 2, page 3, etc.) is accidentally self-canonicalizing each paginated URL instead of pointing back to the root page. - Sitemap conflicts: Pages listed in the sitemap have a canonical tag pointing to a different URL, creating a mismatch. - Blog post syndication or duplication: The same content exists at multiple URLs with inconsistent or missing canonical tags. - Plugin or theme conflicts (external sites): If your site is connected to Search Atlas via integration, an external plugin may be injecting additional canonical tags. 🛠️ Step-by-Step: Diagnosing the Error 1. Go to OTTO SEO → Site Audit in the left sidebar of Search Atlas. 2. Open the latest crawl report and filter for Canonical issues. 3. Click into the Multiple Canonical URLs error to see the full list of affected pages. 4. For each affected page, note the conflicting canonical URLs shown in the report. 5. Open your browser and view the page source (Ctrl+U or Cmd+U) to find all <link rel="canonical"> tags in the <head> section. 6. Also check the HTTP headers of the page using a tool such as a browser extension or developer tools to detect header-level canonical tags. ✅ Step-by-Step: Fixing the Error 1. Remove duplicate canonical tags: Ensure only one canonical tag exists per page, placed in the HTML <head>. Delete any additional or conflicting tags. 2. Fix pagination settings: Paginated pages should either self-canonicalize correctly or use rel="next" and rel="prev" markup. Do not have page 2 canonicalize to page 1 unless that is intentional. 3. Align your sitemap: Make sure every URL in your sitemap matches the canonical URL defined on that page. Remove any URLs from the sitemap that are not the canonical version. 4. Check for HTTP header conflicts: If your server or a caching plugin is adding a Link: <URL>; rel="canonical" header, disable that setting to avoid conflicting with your HTML canonical tag. 5. Re-crawl your site: After making changes, return to OTTO SEO → Site Audit and trigger a new crawl to confirm the errors are resolved. 🔄 Verifying the Fix Once the re-crawl is complete, return to the Canonical issues section of the Site Audit report (OTTO SEO → Site Audit). The 11 affected pages should no longer appear under Multiple Canonical URLs. If any pages remain flagged, repeat the diagnostic steps for those specific 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.

🔍 Optimizing Google Sitelinks for Your Website

🔍 What Are Google Sitelinks? Sitelinks are the additional links that appear beneath your main website listing in Google search results. They help users navigate directly to key sections of your site — for example, Corporate Apparel or Uniforms instead of individual product pages. Google generates sitelinks automatically using its own algorithms, but there are proven steps you can take to guide which pages are selected. ⚙️ How Google Chooses Sitelinks Google's algorithm selects sitelinks based on signals it picks up from your website. The most influential factors are: - Site structure: A clear, logical hierarchy helps Google understand which pages are most important. - Internal linking: Pages that receive more internal links are seen as higher-priority destinations. - Navigation menus: Pages prominently featured in your main navigation are more likely to appear as sitelinks. - Page titles and headings: Descriptive, keyword-rich titles help Google understand what each page is about. - User engagement: Pages that users visit frequently and find useful tend to be favoured. You cannot directly choose your sitelinks inside Google Search Console, but you can strongly influence them by optimising the signals above. 🛠️ Steps to Promote Category Pages as Sitelinks If you want category pages like Corporate Apparel or Uniforms to appear as sitelinks instead of random product pages, follow these steps: 1. Add categories to your main navigation menu. Make sure each target category is listed in your website's primary navigation. Google treats top-level nav links as important pages. 2. Use clear, descriptive page titles. Each category page title should match the label you want to appear in search results — for example, "Corporate Apparel | Your Brand Name". 3. Increase internal links to category pages. Link to your category pages from your homepage, blog posts, and other high-traffic pages. The more internal links a page receives, the stronger the signal to Google. 4. Add a sitemap and submit it in Google Search Console. A well-structured XML sitemap that prioritises category pages helps Google crawl and index them correctly. Submit or update your sitemap under Google Search Console → Sitemaps. 5. Use breadcrumb navigation. Adding breadcrumb markup (schema.org BreadcrumbList) to your pages signals your site hierarchy clearly to Google. 6. Remove or demote pages you don't want as sitelinks. If random product pages keep appearing, reduce internal links pointing to them and ensure they are not featured in your main navigation. 📊 Tracking Your Sitelinks with Search Atlas Use Search Atlas to monitor how your key category pages are performing in organic search, so you can measure whether your optimisations are working: - Go to Left sidebar → Keywords → Rank Tracker to monitor rankings for your category pages. Add keywords like "corporate apparel [your brand]" or "uniforms [your brand]" to track their visibility over time. - Use Left sidebar → Keywords → Keyword Magic to find additional keyword opportunities for your category pages, helping you write stronger titles and headings that Google can match to search queries. - Check Left sidebar → Keywords → Keyword Gap to see how your category pages compare to competitors and identify gaps in your content strategy. ⏳ How Long Does It Take? Sitelinks can take anywhere from a few weeks to several months to update after you make changes. Google recrawls and re-evaluates your site on its own schedule. Continue building internal links, improving page content, and maintaining a clean site structure — consistency delivers results over time. 💡 Quick Checklist - Category pages are listed in the main navigation menu - Page titles are clear and descriptive - Internal links point to category pages from the homepage and key content - XML sitemap is submitted and up to date in Google Search Console - Breadcrumb schema is implemented across the site - Rank Tracker is set up in Search Atlas to monitor category page performance If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Fix Duplicate URLs from Pagination Canonicalization

🧩 Why Duplicate Paginated URLs Appear When Search Atlas crawls your site, it follows every discoverable URL — including paginated versions of your blog posts or archive pages. These are the numbered URLs that look like /blog/post-title/, /blog/post-title/2/, /blog/post-title/3/, and so on. If your paginated URLs are missing a canonical tag — or if each page points to itself rather than the root URL — Search Atlas flags them as duplicate content. This is accurate and expected behaviour: the tool is correctly identifying a canonicalization gap that could harm your search rankings. 📋 Understanding the Problem A paginated URL is only a duplicate risk when one or more of the following is true: - The paginated pages (?page=2, /2/, etc.) have no canonical tag at all. - Each paginated page self-canonicalises instead of pointing back to the root URL. - The root URL does not use a rel="canonical" tag pointing to itself. - Your CMS generates multiple URL formats for the same content (e.g. trailing slash vs. no trailing slash). All five (or more) numbered variants are then treated as separate pages with identical or near-identical content, which is exactly what Search Atlas reports. 🛠️ How to Fix Canonical Links Using OTTO OTTO SEO can apply canonical fixes directly to your site once it is activated and connected. Follow these steps: 1. In the left sidebar, click Site Metrics → Site Explorer to open the Site Explorer. 2. Select the property that contains the duplicate paginated URLs. 3. Review the list of flagged duplicate URLs. Confirm that the affected URLs share a common root path (e.g. the same blog post slug with numeric suffixes). 4. Open OTTO SEO from the left sidebar and ensure OTTO is activated for the correct site. 5. Navigate to OTTO SEO → Site Audit → Issues and look for the Duplicate Content or Canonical task group. 6. Select the flagged paginated URLs and apply the recommended canonical fix. OTTO will set the canonical tag on each paginated page to point to the root (page 1) URL. 7. Click Deploy to push the changes live. 8. Allow 24–48 hours for Search Atlas to re-crawl the pages and clear the duplicate flags. ✅ Best Practices for Pagination Canonicalization To prevent this issue from recurring, follow these canonicalization guidelines: - Root page self-canonicalises: The first page of any paginated series should include a canonical tag pointing to itself (e.g. <link rel="canonical" href="https://yourdomain.com/blog/post-title/" />). - Paginated pages point to root: Pages 2, 3, 4, and beyond should each carry a canonical tag pointing back to the root URL, not to themselves. - Use consistent URL formats: Decide on trailing slash or no trailing slash and apply it consistently across all paginated URLs. - Avoid indexing paginated pages: If paginated pages add no unique value, consider adding noindex alongside the canonical tag to reduce crawl waste. - Test after deployment: Use a browser extension or Google's URL Inspection Tool to confirm the canonical tag is rendering correctly in the HTML source. ❓ Still Seeing Duplicates After Fixing? If the duplicate flags persist after deploying canonical changes through OTTO, check the following: - The site re-crawl may not have completed yet — wait 48 hours and check again. - A caching plugin or CDN may be serving old page versions without the updated canonical tag. Purge your cache after deployment. - Your CMS theme or plugin may be overriding the canonical tags set by OTTO. Review any installed SEO plugins (e.g. Yoast, RankMath) for conflicting canonical settings. - Verify the canonical tag appears in the rendered HTML, not just the source — JavaScript-rendered pages can strip meta tags before they are indexed. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🗺️ Sitemap Tool, Content Genius, and robots.txt Setup

🗺️ Where to Find the Search Atlas Sitemap Tool Search Atlas includes a built-in sitemap generation tool — you do not need a third-party plugin such as Yoast or Rank Math to create your sitemap. The tool is available directly inside the platform. 1. Log in to your Search Atlas account. 2. In the left sidebar, click Site Metrics. 3. Select your target site from the site list. 4. Look for the Sitemap option within the Site Metrics section for your property. If you do not see the Sitemap option, confirm that a site has been added and verified under your account. Only verified properties expose the full set of site tools. ⚙️ How to Generate or Regenerate Your Sitemap 1. Navigate to Site Metrics in the left sidebar and open your site. 2. Open the Sitemap tool. 3. Click Generate Sitemap (or Regenerate if one already exists). 4. Wait for the process to complete — generation time depends on the size of your site. 5. Copy the sitemap URL provided, then submit it to Google Search Console under Sitemaps to ensure Google crawls it promptly. The output is a standard XML sitemap that lists your URLs with their last-modified dates, change frequency, and priority values — fully compatible with Google, Bing, and other search engines. 🚨 Troubleshooting: Google Reads HTML Instead of XML If Google Search Console reports that your sitemap is being read as HTML rather than XML, the sitemap file is likely being intercepted by your hosting environment before it reaches the crawler. This is common on sites hosted behind Cloudflare or Hostinger. Steps to resolve this: - Cloudflare users: Log in to Cloudflare, go to Rules → Page Rules (or Cache Rules), and add a rule to bypass cache for the URL pattern yoursite.com/sitemap*.xml. This prevents Cloudflare from serving a cached HTML version of the page. - Hostinger users: In hPanel, navigate to Hosting → Manage → Cache Manager and clear the full cache. Then add an exclusion for /sitemap.xml so it is never cached as HTML. - All hosts: Open your sitemap URL directly in a browser and view the page source. If you see standard HTML markup instead of XML tags beginning with <?xml, a caching or redirect layer is intercepting the file. Contact your host to exclude the sitemap path from caching rules. - Ensure the sitemap URL does not redirect through a page that loads your site theme before serving the file. 🤖 How to Edit Your robots.txt File Your robots.txt file controls which parts of your site search engine crawlers can access. It must reference your sitemap correctly to support discovery. To edit robots.txt on WordPress: 1. Log in to your WordPress admin panel. 2. Go to Settings → Reading and confirm Search engine visibility is not blocked. 3. Use the Search Atlas Content Genius WordPress plugin (see next section) or access your site files via FTP/hosting file manager. 4. Open or create robots.txt in your site root directory. 5. Add the following line at the bottom, replacing the URL with your actual sitemap address: Sitemap: https://yoursite.com/sitemap.xml 6. Save the file and verify it is accessible at https://yoursite.com/robots.txt in your browser. Avoid blocking /wp-admin/ paths unnecessarily, and never block CSS or JS files that Google needs to render your pages. 🔌 How to Connect Content Genius to Your WordPress Blog Content Genius is the Search Atlas AI writing assistant. Connecting it to WordPress lets you publish optimised content directly from the platform. 1. In the left sidebar, click Content to expand the section. 2. Open Content → Content Genius (page title: "What are we writing today?") at /content/seo-content-assistant. 3. Inside the editor, locate the WordPress Integration or Publish option (top-right area of the editor toolbar). 4. Click Connect WordPress and enter your WordPress site URL. 5. Install the Search Atlas plugin on your WordPress site by uploading the plugin .zip provided by Search Atlas in WordPress → Plugins → Add New → Upload Plugin, then activate it. 6. Copy the API key displayed in Search Atlas and paste it into the plugin settings inside WordPress under Settings → Search Atlas. 7. Return to Search Atlas and click Verify Connection. A success message confirms the integration is live. Once connected, you can draft content inside the SEO Content Assistant and publish or save it as a draft directly to your WordPress blog without leaving Search Atlas. 📋 Understanding Google Instant Indexing and Plan Limits Google Instant Indexing (also called Indexing API or One-Click Indexing) is a premium feature that is not included on all Search Atlas plans. It allows you to request immediate indexing of a URL through the Google Indexing API rather than waiting for Googlebot to crawl it organically. - Check your current plan by going to your Avatar (top-right) → Billing → Plans & Top-ups to see which features are included. - If Instant Indexing is not shown in your dashboard, it means your current plan does not include it. - To unlock this feature, upgrade your plan from the Billing section or speak with our team about the right plan for your needs. - As an alternative, you can manually submit URLs for indexing through Google Search Console → URL Inspection → Request Indexing at no cost. 💬 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.

🔗 Understanding URL Indexer Timelines and Expectations

📋 Overview The URL Indexer tool in Search Atlas accelerates the submission of your URLs to Google's indexing pipeline. However, submission and indexation are two different things. Submitting a URL signals to Google that the page exists and is ready to be crawled — but Google alone decides whether, and when, to index it. This article explains the distinction between submission and indexation, sets realistic timelines, and provides steps you can take if your URLs remain unindexed after several weeks. 🗺️ How to Access the URL Indexer 1. Log in to Search Atlas. 2. Navigate to the URL Indexer tool in your dashboard. ⚙️ Submission vs. Indexation: What's the Difference? These two terms are often confused, but they describe separate stages in the process: - Submission: Search Atlas sends your URLs to Google's Indexing API or ping services. This step confirms that Google has been notified about the URL. It happens quickly — usually within minutes to hours of you submitting the batch. - Indexation: Google crawls the URL, evaluates its quality and relevance, and decides whether to add it to its search index. This step is entirely controlled by Google and cannot be forced or guaranteed by any third-party tool. A "submitted" status in the URL Indexer means your URLs were successfully sent to Google — not that they have been indexed. 📅 Realistic Indexing Timelines Indexing speed varies widely depending on the type of URL you submitted. Use the table below as a general guide: - High-authority, frequently crawled domains (e.g., your main website): A few days to 1–2 weeks. - New or less-established domains: 2–4 weeks on average. - Web 2.0 properties (e.g., Blogger, WordPress.com, Weebly): 2–4 weeks or longer — sometimes 6–8 weeks in practice. Google crawls these domains less frequently and applies stricter quality filters. - Low-quality or thin-content pages: May never be indexed, regardless of submission method. If your URLs were submitted fewer than 10 days ago, it is entirely normal for them to show no indexing activity yet, especially for Web 2.0 properties. Waiting the full 2–4 week window before troubleshooting is strongly recommended. ❓ Why Google May Not Index a Submitted URL Submission does not guarantee indexation. Google may choose not to index a URL for a number of reasons: - The page has thin, duplicate, or low-quality content. - The domain has low authority or very few inbound links. - The page has a noindex directive in the meta tag or HTTP headers. - The page is blocked in robots.txt. - The URL returns a non-200 HTTP status code (e.g., redirect loop, 404, or server error).

🌐 SEO Strategy After a Domain Migration

🔍 Why Domain Migration Affects SEO When you replace your website with a new one at a different URL, search engines treat the new address as an entirely separate site. Without the right steps, you risk losing the rankings, backlink authority, and crawl history your old domain built up over time. Acting quickly and methodically after a migration gives you the best chance of preserving — and even improving — your organic performance. 📋 Step 1: Audit Your Old Domain Before You Do Anything Else Before making changes inside Search Atlas, collect a baseline snapshot of your old domain's performance so you have a reference point. - Export your current keyword rankings from the Rank Tracker for the old domain. - Download a full backlink report from Backlink Research to identify high-value links pointing to the old URLs. - Note your top-performing pages by traffic and ranking position — these need to be prioritised during the migration. 🔀 Step 2: Set Up 301 Redirects on Your Server A 301 redirect tells both users and search engines that a page has permanently moved. This is the single most important technical step in any domain migration. 1. Map every old URL to its equivalent new URL in a spreadsheet. 2. Implement 301 redirects on your server or hosting platform for each mapped URL. 3. Redirect the old homepage to the new homepage as a minimum if a full page-by-page mapping is not possible. 4. Avoid redirect chains — each old URL should redirect directly to the new URL in one hop. Important: Do not rely on JavaScript-based redirects. Server-side 301 redirects are the only method that reliably passes link equity to the new domain. ⚙️ Step 3: Update Your Project in Search Atlas Once your redirects are live, update your Search Atlas workspace to reflect the new domain so all tools track the correct URLs going forward. 1. Locate your existing project in Search Atlas and update the domain to your new URL — the exact steps may vary depending on your account setup, so contact support if you are unsure where to make this change. 2. Re-run a Site Audit on the new domain to surface any crawl errors, missing meta tags, or broken internal links introduced during the migration. 3. Add your new domain to Rank Tracker and import or recreate your keyword list so rankings are monitored from the new URL immediately. 🔗 Step 4: Reclaim and Update Your Backlinks Backlinks pointing to old URLs will follow the 301 redirects, but updating them directly at the source is stronger for long-term authority. - Use the Backlink Research report you exported in Step 1 to identify your most valuable referring domains. - Reach out to those site owners and request they update their links to the new URL. - Prioritise links from high-authority domains and links to your most important pages. ❓ Common Questions After a Domain Migration Customers often contact support after a domain migration because Search Atlas tools such as Rank Tracker or Site Audit are still referencing the old domain, or because ranking data appears to drop or disappear after the change. If this happens to you: - Confirm your 301 redirects are live and returning the correct HTTP status code before expecting ranking recovery. - Allow search engines 4–12 weeks to fully re-index the new domain — some fluctuation in rankings during this window is normal. - If your Search Atlas project is still pulling data for the old domain, reach out to support so a team member can guide you through updating your project to the new domain correctly. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Using Search Atlas with Noindex Staging Sites

🚧 Understanding the Noindex Constraint If your staging site uses a noindex directive (for example, via a robots.txt disallow rule or a noindex meta tag), Search Atlas tools that rely on automated crawling — including Site Audit and content imports in Content Genius — cannot access or process that site. This is not a platform limitation you can work around with settings; it is a deliberate crawl block that prevents any crawler, including Search Atlas, from reading your pages. This means that if your rebuilt site is live at a staging subdomain such as beta.snazzy.solutions but is set to noindex, the automated workflows described in some help resources will not work until the noindex restriction is lifted. ✅ What You Can and Cannot Do It helps to know exactly where the boundary is before choosing a workflow: - Cannot do: Run a Site Audit crawl against a noindex staging subdomain. - Cannot do: Auto-import staging pages into Content Genius via URL crawl. - Can do: Paste page content manually into Content Genius for AI-powered feedback. - Can do: Use Content Genius to audit and optimise individual pages by entering copy directly. - Can do: Run a full Site Audit and content review once the site is live and indexable, or once the noindex restriction is temporarily removed in a controlled way. 📋 Option 1 — Manual Content Review in Content Genius This is the recommended approach when your staging site is noindex and you need pre-launch feedback on page quality, SEO signals, and content gaps. 1. Open Search Atlas and navigate to Content → Content Genius (What are we writing today?). 2. Create a new document or open an existing one. 3. Copy the text content from your staging page (title, headings, body copy, meta description). 4. Paste the content into the Content Genius editor. 5. Enter your target keyword and configure the settings as you would for any new piece of content. 6. Use the AI suggestions, content score, and NLP recommendations to identify gaps and improvements. 7. Repeat this process for each key page you want to review before launch. While this approach requires more manual effort than an automated crawl, it gives you detailed, per-page feedback that is fully actionable before the site goes live. 🛠️ Option 2 — Temporarily Remove Noindex for Crawling If your team can safely control access to the staging environment, you may choose to temporarily remove the noindex directive to allow a Site Audit crawl. Use this option only if your staging subdomain is password-protected or otherwise not publicly discoverable, so that search engines do not accidentally index incomplete content. 1. Work with your developer to remove or disable the noindex rule on the staging subdomain. 2. Ensure the subdomain is protected by HTTP authentication or IP restriction so it remains inaccessible to search engine bots during this window. 3. In Search Atlas, go to OTTO SEO → Site Audit in the left sidebar and add your staging subdomain as a new project. 4. Run the audit and review all flagged issues — broken links, missing meta tags, heading structure, page speed signals, and more. 5. Export or document the findings, then restore the noindex directive on the staging site before making anything public. 6. Apply all fixes to the staging build before your production launch. This option gives you the full power of Site Audit but requires coordination with your development team and careful access controls. 🚀 Option 3 — Run a Full Audit Post-Launch If neither manual review nor temporary crawl access is practical before launch, the most straightforward path is to launch the site, confirm indexing is enabled, and then immediately run a Site Audit in Search Atlas. 1. Before going live, make sure all noindex directives are removed from production pages you want indexed. 2. After launch, go to OTTO SEO → Site Audit in the left sidebar and create a new project using your live production domain. 3. Run the audit within the first day of launch to catch and fix any technical issues before they affect rankings. 4. Use Content Genius to review and optimise priority pages using the live URLs once they are crawlable. Pairing a fast post-launch audit with pre-launch manual reviews in Content Genius gives you strong coverage at both stages. ⚡ Quick Reference — Which Workflow Fits Your Situation - Need feedback now, site is noindex: Use manual copy-paste into Content Genius (Option 1). - Can protect staging with a password and remove noindex temporarily: Run Site Audit on staging (Option 2). - Launch is imminent and no access changes are possible: Plan a same-day post-launch audit (Option 3). 💬 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.

🔄 Cancel and Restart Stuck Site Crawls

🧭 Overview Site crawls in Search Atlas usually complete within a few hours, depending on the size of your website. If a crawl has been running for more than 24 hours without finishing, it is likely stuck. This article explains how to cancel a stuck crawl and restart it so your site audit can complete successfully. ⚠️ Signs Your Crawl May Be Stuck - The crawl progress has not moved for several hours. - The crawl status still shows as in progress after more than 24 hours. - No new data or pages have appeared in the audit report. - The crawl has been running for multiple days with no completion. 🛑 How to Cancel a Stuck Crawl 1. In the left sidebar, navigate to your project and open Site Auditor. 2. Locate the crawl session that has been running without completing. 3. Find the option to cancel or stop the active crawl session — this is typically available alongside the crawl session entry in the auditor interface. 4. Confirm the cancellation and wait a few seconds for the status to update before proceeding. Note: Cancelling a crawl does not delete any previously collected data. Any pages already crawled before cancellation remain available in your audit history. 🔁 How to Restart the Crawl 1. Once the previous crawl is cancelled, look for the option to initiate a new crawl session within the Site Auditor for your project. 2. Review your crawl settings before confirming — check the crawl scope, crawl limit, and any URL exclusion rules. 3. Start the new crawl session and monitor its progress from within the Site Auditor interface. If you made no changes to your crawl settings, the recrawl will use the same configuration as your previous session. 🛠️ Things to Check Before Restarting Before you restart the crawl, consider the following adjustments to help prevent it from getting stuck again: - Reduce the crawl limit if your site has a very large number of pages — crawling a smaller subset can help complete the audit faster. - Review URL exclusion rules to make sure the crawler is not being caught in redirect loops or crawling unintended sections of your site. - Check your crawl scope to ensure it is set appropriately for the size of the site you are auditing. 📋 What to Have Ready If You Need Support If your crawl continues to get stuck after cancelling and restarting, our team can investigate on the backend. Please have the following ready when you reach out: - Your project name and the URL of the site being crawled - The approximate date and time the crawl started - A description of what you see in the Site Auditor (e.g. whether the status appears frozen or unchanged) - Any error messages displayed in the interface If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🕷️ OTTO SEO Crawl Volume and Schedule Explained

🔍 Overview If your site has a large number of pages, you may notice that OTTO SEO has crawled and indexed fewer pages than your total page count. This is expected behaviour. OTTO uses a smart crawling system designed to prioritise the pages most likely to impact your SEO performance, while keeping resource usage efficient for your site. 📊 Why OTTO Indexes a Subset of Your Pages OTTO does not crawl every page on your site in a single pass. Instead, it works through your pages progressively, applying the following logic: - Priority-based crawling: OTTO focuses first on your highest-value pages — typically those already receiving organic traffic, linked from your sitemap, or flagged as important in your site architecture. - Crawl budget allocation: Each connected site is assigned a crawl budget based on your Search Atlas plan. This budget controls how many pages OTTO processes per crawl cycle. - Incremental indexing: Pages are added to OTTO's index over multiple crawl cycles. A site with 65,000 pages will not be fully indexed after a single crawl — this is normal and by design. - Duplicate and low-value page filtering: OTTO automatically excludes near-duplicate pages, thin content pages, and URLs blocked by your robots.txt or noindex directives, which can reduce the indexed count compared to your total page count. In the example of a 65,000-page site showing 16,000 indexed pages, this reflects the progress of the current crawl cycle combined with priority filtering. The indexed count will grow with each subsequent crawl. 🕐 When Does OTTO Crawl Your Site? OTTO is designed to crawl during off-peak hours to minimise any impact on your site's performance and server load. Here is what you need to know about the crawl schedule: - Off-peak timing: Crawls are scheduled to run during low-traffic periods, typically overnight based on the time zone associated with your Search Atlas account. - Automatic scheduling: You do not need to manually trigger crawls. OTTO manages the schedule automatically once it is activated for your site. - Recurring cycles: OTTO re-crawls your site on a regular basis to detect new pages, content changes, and resolve previously identified issues. The frequency depends on your plan tier. - On-demand crawl triggers: If you publish a large batch of new pages or make significant structural changes, you can manually request a fresh crawl from within the OTTO dashboard to accelerate indexing. 🛠️ How to Check Crawl Status and Progress 1. Log in to Search Atlas and navigate to OTTO SEO → All Sites (SEO Automation) in the left sidebar, or go directly to /seo-automation-v3. 2. Select the site you want to review from the site selector at the top of the page. 3. Review the crawl summary panel, which shows the total pages discovered, pages indexed, and the timestamp of the last completed crawl. 4. Check the Crawl Progress indicator to see how far through the current cycle OTTO has progressed. 5. If you have recently added new pages and want OTTO to pick them up sooner, use the Trigger Crawl option if available on your plan. 💡 Tips to Improve Crawl Coverage - Submit an updated XML sitemap: Ensure your sitemap is connected to OTTO and reflects your full page inventory. OTTO uses the sitemap as a primary discovery source. - Audit your robots.txt: Confirm that important pages are not unintentionally blocked from crawling. - Remove noindex tags from pages you want indexed: OTTO respects noindex directives and will exclude those pages from its count. - Reduce redirect chains: Long redirect chains slow down crawling and can cause pages to be skipped within a given cycle. - Upgrade your plan for a higher crawl budget: If your site grows significantly, a higher-tier plan increases the number of pages OTTO can process per cycle. ❓ Frequently Asked Questions Will OTTO eventually index all 65,000 pages? Yes — over multiple crawl cycles OTTO will work through your full page inventory, subject to your plan's crawl budget. Pages that are accessible, indexable, and not filtered as low-value will be added incrementally. Does crawling affect my site speed? OTTO's off-peak scheduling and rate-limited crawling are specifically designed to avoid impacting your site's performance or server response times. Why did the indexed page count drop? A drop in indexed pages usually means OTTO detected that some pages became noindexed, were removed, returned errors (such as 404s), or were filtered out as duplicates during the latest crawl cycle. 🙋 Still Need Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix WordPress Crawls and Onboard Agency Clients

🔍 Overview This article covers two common questions from new agency users: why a WordPress site may not crawl after connecting, and how to get the most out of Search Atlas when onboarding new clients. Follow the steps below to resolve crawl issues and explore the platform's core capabilities. ⚙️ Why Your WordPress Site Isn't Crawling After connecting WordPress to Search Atlas, a crawl may fail to start or return no data. This is almost always caused by one of the following: - Plugin not activated: The Search Atlas WordPress plugin must be installed and activated on your site. Without it, the platform cannot communicate with your WordPress installation. - Incorrect site URL: The URL entered during connection must exactly match your WordPress site address, including whether it uses www or not, and https vs http. - Firewall or security plugin blocking crawlers: Plugins such as Wordfence, Cloudflare firewall rules, or password-protected staging environments can block the Search Atlas crawler. Temporarily whitelist the crawler IP or disable bot-blocking rules during the crawl. - robots.txt disallowing crawl: Check your robots.txt file to ensure it does not block all bots or the Search Atlas user agent. - Site is not publicly accessible: If your WordPress site is in maintenance mode or behind a login wall, the crawler cannot access it. 🔧 Steps to Fix a WordPress Crawl 1. Log in to your WordPress admin dashboard and confirm the Search Atlas plugin is installed and active under Plugins → Installed Plugins. 2. In Search Atlas, navigate to your site settings and verify the connected URL matches your live WordPress address exactly. 3. Check your robots.txt file by visiting yourdomain.com/robots.txt. Make sure no Disallow: / rule is blocking all bots. 4. If you use a security plugin or Cloudflare, temporarily pause bot-protection rules and attempt the crawl again. 5. Ensure the site is publicly accessible — disable maintenance mode and remove any login requirements on the front end. 6. Return to Search Atlas, open your project, and trigger a new crawl manually. If the crawl still does not complete after following these steps, if you need further assistance, open 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 Agencies Onboard New Clients in Search Atlas Search Atlas is built with agencies in mind. Here is how to structure your workflow when bringing on a new client: 1. Create a new project: Each client gets their own project inside Search Atlas. Navigate to your dashboard (Home) and select Create Project, then enter the client's domain. 2. Connect their WordPress site (if applicable): Install the Search Atlas plugin on the client's WordPress site and connect it to the project following the steps above. 3. Run a site audit: Trigger a crawl to identify technical SEO issues such as broken links, missing meta tags, slow pages, and crawl errors. Share the audit report with your client as a baseline. 4. Set up keyword tracking: Add the client's target keywords to the Rank Tracker to monitor positions over time and measure the impact of your work. 5. Use OTTO SEO for automation: Navigate to Left sidebar → OTTO SEO → All Sites (SEO Automation) (URL: /seo-automation-v3) to activate OTTO, Search Atlas's AI-powered SEO automation. OTTO can automatically fix on-page issues, deploy schema, and optimise content at scale — saving agencies significant time across multiple clients. 🔗 Search Atlas Backlink Capabilities for Agencies Search Atlas includes a comprehensive backlink intelligence suite that agencies can use to analyse, monitor, and build links for clients: - Backlink Analyzer: Enter any domain to see its full backlink profile, including referring domains, anchor text distribution, domain authority, and link types (dofollow vs nofollow). - Competitor backlink gap: Compare your client's backlink profile against competitors to identify link-building opportunities they are missing. - Link monitoring: Track newly acquired and lost backlinks over time so you can demonstrate link-building ROI to clients. - Prospecting data: Use the platform's database to find high-authority sites in your client's niche for outreach campaigns. These tools are available directly within each client project, making it easy to generate white-label-ready reports and insights for your agency deliverables. 💡 Agency Best Practices - Use separate projects for each client to keep data, crawls, and reports isolated and organised. - Schedule regular crawls so you catch technical regressions before they affect rankings. - Combine the backlink analyzer with keyword tracking to build a full-picture SEO strategy for each client. - Use OTTO SEO to handle repeatable optimisation tasks so your team can focus on strategy and client communication. If you need further assistance, open the 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 Indexing Access Errors

🔍 Overview When enabling Google Search Console (GSC) indexing access in Search Atlas, you may encounter an error if the required Google Cloud Platform (GCP) credentials have not been configured correctly. This article walks you through generating a GCP JSON key and granting the Search Atlas service account the permissions it needs to connect successfully. 📋 Before You Begin Make sure you have the following ready before starting: - A Google account with access to Google Cloud Platform (GCP) - Owner or Editor access to the GCP project linked to your Google Search Console property - Admin access to your Search Atlas account ⚙️ Step 1: Create or Select a GCP Project 1. Go to console.cloud.google.com and sign in with your Google account. 2. In the top navigation bar, click the project selector and either choose an existing project or click New Project to create one. 3. Make sure the project is linked to the same Google account that manages your Search Console properties. 🔑 Step 2: Enable the Google Search Console API 1. Inside your GCP project, navigate to APIs & Services → Library. 2. Search for Google Search Console API and click on it. 3. Click Enable. If it is already enabled, you will see a Manage button instead — no further action is needed here. 📄 Step 3: Create a Service Account 1. In the left-hand GCP menu, go to IAM & Admin → Service Accounts. 2. Click Create Service Account. 3. Enter a name and an optional description, then click Create and Continue. 4. For the role, select Owner or Editor to grant sufficient permissions, then click Continue. 5. Click Done to finish creating the service account. 📥 Step 4: Generate a JSON Key 1. On the Service Accounts page, click the service account you just created. 2. Go to the Keys tab and click Add Key → Create New Key. 3. Select JSON as the key type and click Create. 4. A JSON file will automatically download to your device. Keep this file safe — it contains sensitive credentials. 👥 Step 5: Add the Service Account to Google Search Console 1. Open Google Search Console at search.google.com/search-console. 2. Select the property you want to connect to Search Atlas. 3. In the left sidebar, click Settings → Users and permissions. 4. Click Add User and enter the service account email address (ending in @your-project-id.iam.gserviceaccount.com). 5. Set the permission level to Full and click Add. 🚀 Step 6: Upload the JSON Key in Search Atlas 1. Log in to Search Atlas and navigate to Site Metrics → Site Explorer, then click the GSC link to open Manage Sites/Connect GSC Account (/gsc/sites-list). 2. When prompted, upload the JSON key file you downloaded in Step 4. 3. Save your settings. Search Atlas will validate the credentials and establish the connection. 4. If the connection is successful, you will see a confirmation that GSC indexing access is enabled. ⚠️ Common Errors and Fixes - Invalid credentials error: Ensure the JSON file uploaded matches the service account that was added to Search Console. Re-download the key if needed. - Permission denied error: Confirm the service account has been added to the correct Search Console property with Full access. - API not enabled error: Return to GCP and verify the Google Search Console API is enabled for the correct project. - Wrong project selected: Double-check that the GCP project, service account, and Search Console property are all associated with the same Google account. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Why Your Submitted URLs Aren't Getting Indexed

🗺️ Overview The URL Indexer tool in Search Atlas helps you request faster crawling and indexing of your URLs by search engines. However, submitting a URL does not guarantee it will be indexed — and in some cases, the process can take longer than expected. This article explains why that happens and what steps you can take. ⚙️ How the URL Indexer Works When you submit URLs through Left sidebar → Authority → Indexer (URL Indexer), Search Atlas sends indexing requests to search engines on your behalf using protocols like IndexNow. Here is what happens after submission: 1. Your URLs are queued and submitted to supported search engines. 2. Search engines receive the ping and add the URLs to their crawl schedule. 3. The search engine crawler visits and evaluates the page. 4. If the page meets quality criteria, it is added to the index. Steps 3 and 4 are entirely controlled by the search engine — Search Atlas cannot force or speed up those stages. ⏱️ Why Indexing Can Take Longer Than Expected Even after a successful submission, URLs may not appear in search engine indexes for days or even weeks. Common reasons include: - Search engine crawl queue: Search engines prioritise URLs based on their own signals. New or low-authority domains are often crawled less frequently. - Page quality signals: If a page has thin content, duplicate content, or poor technical SEO, search engines may crawl it but choose not to index it. - Crawlability issues: A noindex tag, robots.txt block, or server error (such as a 404 or 500) will prevent indexing regardless of submission. - Domain authority: Newer domains with few backlinks tend to be indexed more slowly than established sites. - Search engine processing time: Even under normal conditions, it can take 1–4 weeks for some URLs to be indexed after a successful submission request. ✅ Steps to Troubleshoot Unindexed URLs Follow these steps before concluding there is a platform issue: 1. Check the URL format: Make sure every URL starts with https:// (e.g., https://yourdomain.com/page). URLs submitted without the correct protocol may not be processed correctly. 2. Verify the page is crawlable: Use Google Search Console or a site audit tool to confirm the URL returns a 200 status code, has no noindex directive, and is not blocked by robots.txt. 3. Confirm content quality: Ensure the page has unique, substantive content. Thin or duplicate pages are frequently crawled but not indexed. 4. Check your submission status: Go to Left sidebar → Authority → Indexer (URL Indexer) and review whether your URLs show a confirmed submitted status. If URLs are missing from the list but your quota was deducted, see the note below. 5. Allow sufficient time: If fewer than 14 days have passed since submission, continue to wait. Indexing timelines vary significantly by search engine and domain. 6. Resubmit if needed: If more than 14 days have passed, the page is technically sound, and the URL still does not appear in search results, try resubmitting it through the URL Indexer. ⚠️ Known Issues and Current Status Our team has investigated and resolved several technical issues related to the URL Indexer, including: - URLs submitted via file upload or manual entry not always appearing in the final submission list. - Quota being deducted even when submissions did not process correctly. - A silent network error that, in some cases, prevented URLs from being submitted to search engines on the production environment. These issues have been resolved. If you submitted URLs during a period when you experienced any of the above problems, we recommend resubmitting those URLs to ensure they are properly processed. If you believe your quota was incorrectly deducted, please reach out via the live chat widget so our team can review your account. 💡 Tips for Faster Indexing While no method guarantees instant indexing, these best practices can improve your results: - Submit URLs for pages that are linked from other indexed pages on your site — internal links help crawlers discover and prioritise new content. - Build at least one external backlink to the page before or shortly after submitting. - Submit your sitemap to Google Search Console and Bing Webmaster Tools in addition to using the URL Indexer. - Ensure your site loads quickly and is mobile-friendly, as these are positive crawl priority signals. 💬 Still Need Help? If you have followed the steps above and your URLs are still not indexing after 14+ days, or if you suspect a platform issue such as incorrect quota deductions, we are here to help. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Pixel Installation, Duplicates, and Visibility Discrepancies

🧭 Overview If a client confirms their pixel is installed and firing correctly on their website but it still does not appear inside Search Atlas, you are not alone. This is one of the most common questions our support team receives. This article explains why that gap exists, what duplicate pixel installations mean for your data, and how to resolve both issues quickly. ❓ Why Doesn't My Pixel Appear in Search Atlas? Search Atlas detects pixels by scanning the pages it crawls. There are several reasons a confirmed, working pixel may still not show up inside the platform: - Crawl timing: Search Atlas crawls pages on a scheduled basis. If the pixel was installed recently, the platform may not have re-crawled the page yet. Allow up to 24–48 hours after installation before expecting the pixel to appear. - Tag Manager delay: Pixels deployed through Google Tag Manager or a similar container may load asynchronously or only under specific trigger conditions (e.g., after a button click or form submission). If the trigger has not fired during a crawl, Search Atlas will not detect the pixel. - Consent management platforms: If a cookie consent banner or CMP blocks the pixel from loading until a user accepts cookies, the Search Atlas crawler — which does not interact with consent banners — will never see the pixel fire. - SPA or JavaScript-rendered pages: On single-page applications, pixels may load only after client-side JavaScript executes. Depending on the crawl configuration, the pixel could be invisible to the scanner even when it works perfectly for real users. - Incorrect placement: The pixel code may be placed in a location the crawler does not reach, such as deep inside a shadow DOM element or inside an iframe. ⚠️ Is Having Duplicate Pixel Installations Harmful? Yes, duplicate pixels can cause real problems. Having the same pixel fire more than once per page visit leads to the following issues: - Inflated event data: Conversions, page views, and custom events are counted multiple times, making your analytics and ad platform reporting unreliable. - Wasted ad spend: Ad platforms such as Meta and Google use pixel data to optimise bidding. Duplicate signals skew the data they rely on, which can result in higher costs and lower campaign performance. - Audience pollution: Remarketing audiences built from pixel data become inaccurate when the same user is counted multiple times per session. - Slower page load: Every duplicate pixel fires additional network requests, which can marginally slow page performance. A single, correctly configured pixel per platform is always the recommended setup. 🛠️ How to Diagnose and Fix the Issue 1. Verify the pixel is live on the page: Use a browser extension such as Meta Pixel Helper, Google Tag Assistant, or a general tag debugger to confirm the pixel fires on the specific URL you are checking inside Search Atlas. 2. Check for consent or trigger conditions: If a CMP is active, temporarily bypass it in a private browser session to confirm the pixel loads without the consent wall. If the pixel only fires after consent, note that Search Atlas will not detect it through passive crawling alone. 3. Search for duplicates: In the same browser extension or in your browser's Network tab (filter by the pixel domain), look for the pixel request firing more than once per page load. If it fires twice, check both your direct HTML and your tag manager container for duplicate entries and remove one. 4. Trigger a re-crawl in Search Atlas: After confirming the pixel is live and non-duplicate, navigate to the relevant section of the platform and initiate a re-crawl or refresh of the page data so Search Atlas picks up the latest state. 5. Confirm the correct URL is being checked: Make sure the URL you are viewing inside Search Atlas exactly matches the URL where the pixel is installed, including any trailing slashes or protocol differences (http vs https). ✅ Quick Reference: Pixel Not Showing vs. Duplicate Pixel - Pixel confirmed working but not in Search Atlas → Wait for re-crawl, check consent settings, verify trigger conditions, and ensure the pixel fires on the exact crawled URL. - Pixel appearing multiple times per page → Audit your tag manager container and direct HTML for duplicate entries; keep only one instance active per platform. 💬 Still Need Help? If you have followed the steps above and the pixel still does not appear in Search Atlas, or if you are unsure whether your setup contains duplicates, If you need further assistance, open 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: How to Find Newly Added Audits

🤔 Why your new audit does not appear When you add URLs and start a new site audit, the audit is created and begins processing correctly — but it is added to the bottom of your All Audits list, not the top. If you have several existing audits, the new one may not be visible without scrolling or loading more results. 📍 How to find your audit 1. Go to OTTO SEO → Site Audit in the left sidebar of your Search Atlas dashboard 2. On the All Audits page, scroll to the bottom of the list 3. Click Load More to reveal additional audits 4. Your new audit will appear at the bottom of the expanded list The All Audits page also has a sort control shown as Sorting: Recently Added. It is easy to overlook because it does not look interactive, but you can use it to reorder the list and help bring your most recent audit into view. An update to this page is in development to make the sort control more discoverable and to surface common actions (such as Recrawl and Crawl Settings) directly on each audit card. ⏳ The audit is still processing Newly created audits may show a processing or crawling status while Search Atlas scans your URLs. This is normal and can take a few minutes depending on the size of your site. 🆘 Still cannot find it? If the audit does not appear even after clicking Load More and waiting a few minutes, it is possible it was never created because the URL failed a pre-audit validation check. When validation fails, the Create Site Audit modal normally shows a red alert box describing the problem — for example the site being unreachable, a bad SSL certificate, or the homepage redirecting to an external domain. Note that some validation failures — such as a blocked (non-public) domain or a site that returns an HTTP error — may currently fail without an on-screen message; clearer messaging for these cases is in development. If a brand-new audit never appears, confirm the URL is publicly accessible, online, and returns no errors, then try creating it again. If you still cannot locate the audit, contact support with the URL you submitted and the date/time you created the audit.

☁️ Cloud Stack Indexation: Why Google Indexes Only Some Sites

🔍 Overview If you have deployed a cloud stack and only a portion of the sites are showing as indexed in Google, this is expected behavior — not a sign that something has gone wrong. Partial indexing is a normal part of how Google processes large groups of new URLs, especially those hosted on cloud infrastructure. This article explains why it happens, what you should do next, and how batch deployment can improve your results. ☁️ What Is a Cloud Stack? A cloud stack is a group of web properties built on cloud platforms (such as Google Sites, Amazon AWS pages, or similar) and linked together to pass authority to your target URL. You can create and manage your cloud stacks inside Search Atlas by navigating to Authority → Cloud Stacks in the left sidebar. 📊 Why Does Google Only Index Some Cloud Stack Sites? Google does not index every page or property it discovers at the same time. When a large batch of new URLs is submitted or crawled together, Google's systems prioritize and process them gradually. Several factors influence which sites get indexed first: - Crawl budget allocation: Google assigns a crawl budget to each domain. New cloud properties compete for crawl attention alongside other content on those platforms. - Trust and authority signals: Pages that receive more internal links or external signals get crawled and indexed faster. - Platform-level throttling: Cloud hosting platforms may throttle how quickly new pages are made discoverable to search engines. - Content similarity detection: If multiple properties in your stack share very similar content or structure, Google may deprioritize indexing some of them temporarily. - Age of the property: Newer properties take longer to earn indexation than established ones. Seeing only a subset of your cloud stack indexed within the first days or weeks is completely normal. Indexation of the remaining properties typically continues rolling in over time as Google processes the queue. 🚫 Should You Delete Un-Indexed Sites? No. Do not delete or abandon un-indexed cloud stack properties. Here is why: - A site not yet indexed is not a failed site — it is a site still in Google's processing queue. - Deleting properties removes link equity that is already being passed, even before indexation is confirmed. - Re-creating properties restarts the clock on crawl discovery and trust signals. - Un-indexed properties still contribute to the overall network structure that supports indexed ones. The correct approach is to wait, monitor, and apply the indexation tips covered in the next section. ✅ How to Improve Indexation of Cloud Stack Sites Use these proven steps to accelerate and improve your cloud stack indexation rate: 1. Submit URLs to the URL Indexer: Use the URL Indexer tool inside Search Atlas to submit your cloud stack URLs and prompt faster crawling. 2. Use batch deployment strategically: Rather than deploying all cloud stack properties at once in a single burst, consider staggering deployments in batches. This helps avoid triggering platform-level throttling and allows Google to process each group before the next is submitted. 3. Build links to your cloud properties: Adding internal and external links pointing to your cloud stack properties improves their authority signals and encourages faster crawling. 4. Avoid duplicate content across properties: Differentiate the content or structure across your cloud stack sites where possible to reduce the chance of Google deprioritizing similar pages. 5. Be patient and monitor progress: Check indexation status periodically using Google Search Console or site search operators. Indexation is a gradual process for large batches of new URLs. 📦 When to Use Batch Deployment Batch deployment is recommended when you are building a large cloud stack. Deploying properties in smaller, spaced-out groups rather than all at once gives each batch time to be discovered and processed by Google before the next group is submitted. This strategy can result in higher overall indexation rates across your full cloud stack. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Understanding Your Schema Markup Detection Ratio

🧩 What Does the Schema Detection Ratio Mean? When Search Atlas audits your site, it checks every crawled page for valid schema markup. The ratio displayed — for example, 1/124 — means that out of 124 pages crawled, only 1 page was found to have detectable, properly implemented schema markup. This does not necessarily mean your schema deployment failed entirely. It means the tool found schema on fewer pages than expected based on your total crawled page count. ⚠️ Common Reasons for a Low Detection Ratio - Schema applied to one page only: If you deployed schema to a single page (such as your homepage) but not site-wide, only that page will register. - JavaScript-rendered schema: Schema injected via JavaScript may not be picked up if the crawler processes pages before the script executes. Search Atlas recommends implementing schema in raw HTML or via server-side rendering. - Incorrect placement: Schema must be placed inside a <script type="application/ld+json"> tag within the page's HTML. Incorrect tag types or malformed JSON will cause detection to fail. - Noindex or blocked pages: Pages blocked by robots.txt or marked noindex may be crawled but schema on those pages will not count toward your accessible inventory. - Plugin or CMS conflicts: If you are using a WordPress plugin or CMS extension to deploy schema, conflicts with caching plugins or theme code can strip the markup before the page is served. - Schema only on specific page types: If your schema is scoped to product pages, blog posts, or FAQs and your site has a large number of other page types, the ratio will appear low by design. 🛠️ How to Diagnose the Issue 1. Open Search Atlas and navigate to OTTO SEO → Site Audit in the left sidebar to view your report. 2. Locate the schema markup finding and click through to see which specific URLs have schema detected versus which do not. 3. Pick a sample URL that should have schema and paste it into Google's Rich Results Test (search.google.com/test/rich-results) to confirm whether schema is visible to crawlers. 4. View the raw page source (right-click → View Page Source in your browser) and search for application/ld+json. If it does not appear, the markup is either missing or rendered client-side only. 5. Validate your schema JSON using Schema.org's validator (validator.schema.org) to catch syntax errors or missing required properties. ✅ How to Improve Your Schema Coverage - Deploy schema site-wide where appropriate: Add Organisation or WebSite schema globally, and use page-specific schema types (Article, Product, FAQPage, BreadcrumbList) on the relevant templates. - Use server-side or static HTML implementation: Avoid relying solely on JavaScript to inject schema. Ensure the markup is present in the initial HTML response. - Update your CMS template files: If your site uses a CMS like WordPress, Shopify, or Webflow, add schema to your theme templates so it applies to all pages of a given type automatically. - Re-crawl after changes: Once you have made updates, trigger a new crawl in Search Atlas so the tool picks up your changes and recalculates the detection ratio. - Prioritise high-value pages first: If a full site-wide rollout is not immediately possible, focus on your top landing pages, product pages, and blog posts to increase coverage quickly. 📊 What Is a Healthy Schema Ratio? There is no single universal benchmark, as the ideal ratio depends on your site's content and goals. However, as a general guide: - Most pages that are publicly accessible and indexable should carry at least one schema type. - A ratio below 10% on a content-heavy site typically indicates a deployment gap worth addressing. - Purely functional pages such as login, cart, or account pages do not require schema, so some gap is normal and expected. The goal is to ensure that every page where schema would add value to search engines — product pages, articles, local business pages, FAQs — is covered. 💬 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.

🔄 Reset Project Data After Website Rebuild or Migration

🧭 Overview When you rebuild your website, switch themes, or migrate to a new platform (such as moving to a new Shopify theme), Search Atlas may continue surfacing SEO issues tied to your old site structure. This happens because your project is still linked to the previous website configuration. This article explains how to reset your project data so it accurately reflects your new site. ⚠️ Why Old SEO Issues Keep Appearing Search Atlas stores a snapshot of your website's structure, pages, and technical SEO data when a project is first crawled and connected. After a major rebuild or theme migration, this stored data becomes outdated. Common symptoms include: - SEO issues flagged for pages that no longer exist - Missing recommendations for new pages added during the rebuild - OTTO continuing to reference your old WordPress setup after migrating away - Audit scores that do not reflect your current site 🛠️ Step 1 — Disconnect Your Old Site Connection If your project was previously connected to a WordPress site and you have since migrated away, the WordPress link must be cleared before new data can be pulled correctly. 1. Log in to your Search Atlas account. 2. Navigate to the project affected by the migration. 3. Open OTTO SEO for that project. 4. Go to the project settings and look for the connected site or WordPress integration. 5. Select the option to disconnect or unlink the existing site connection. If you do not see a disconnect option, or if your project is one of the cases where the WordPress link is stuck, contact support using the chat widget (see the end of this article). Our team can manually unlink the old connection on your behalf. 🔍 Step 2 — Re-Crawl Your Website Once the old connection is cleared, trigger a fresh crawl so Search Atlas can index your rebuilt site from scratch. 1. From the left sidebar, go to Website Studio (or navigate to /website-studio). 2. Select your project from the project list. 3. Locate the Crawl or Re-crawl Site option within the project settings. 4. Confirm the crawl. Depending on your site size, this may take a few minutes to complete. Once the crawl finishes, Search Atlas will display SEO data based on your current site structure, not your previous theme or build. 📊 Step 3 — Review and Re-Activate OTTO After the re-crawl is complete, review your OTTO SEO recommendations to ensure they reflect your new site. 1. Open OTTO SEO for the project. 2. Check that the connected domain matches your live, rebuilt website. 3. Review the updated list of SEO tasks and deploy fixes that apply to your new theme or structure. 4. Dismiss or archive any tasks that were carried over from the old site if they no longer apply. Note: If OTTO is still showing tasks from your old site after the re-crawl, try deactivating and reactivating OTTO on the project to force a full refresh of its task list. 💡 Tips for a Smooth Reset - Do this after your new theme or site is fully live — crawling a site that is still mid-migration may produce inaccurate results. - Check your sitemap — make sure your new site has an updated sitemap submitted so the crawler picks up all new pages. - Allow up to 24 hours for all metrics and scores to fully update across your dashboard after a re-crawl. - Shopify users: If you switched to a new Shopify theme that significantly changed your URL structure, treat this as a full site migration and follow all steps above from the beginning. 🙋 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⏳ OTTO Pixel Installation: Crawl Status and Timeline

🔍 Overview After installing the OTTO pixel — either via the WordPress plugin or manual code snippet — you may notice that the pixel status inside the platform does not immediately change to confirmed. This is expected behavior. The status update depends on the completion of a site audit crawl, which may take some time depending on your site's size and structure. This article explains the difference between a successful installation and a confirmed status, and what to expect while the crawl is underway. ✅ Installation Success vs. Status Confirmation These are two separate events, and it is important not to confuse them: - Successful installation means the OTTO pixel code is correctly placed on your site, either through the activated WordPress plugin or a manually added snippet. No further action is needed on your end once this step is complete. - Status confirmation means Search Atlas has detected the pixel during a site audit crawl and has updated the dashboard to reflect it. This happens automatically — but only after the crawl finishes. If your plugin is activated and your API credentials are correctly entered, your installation is likely already successful. The pending status simply means the crawl has not yet reached and verified your pages. 🔄 Site Audit Crawl and Timing Once the OTTO pixel is installed, Search Atlas runs a site audit crawl to detect and confirm the pixel across your pages. During this crawl, the dashboard status may remain in a pending or unconfirmed state. This is normal — the status will update automatically once the crawl has completed and the pixel has been detected. The time required for the crawl to complete can vary. Larger or more complex sites with many pages will naturally take longer to process than smaller sites. If your status has not updated, the most likely explanation is that the crawl is still in progress. 📊 What to Do While Waiting While the crawl is underway, no action is required on your part. You do not need to reinstall the pixel or make any changes. Simply allow time for the crawl to complete. Once it finishes, your pixel status will update automatically in the platform dashboard. If your pixel status remains unconfirmed after an extended period and you believe your installation is correctly set up, please reach out to our support team with your project name and any relevant details about how you installed the pixel (WordPress plugin or manual snippet). If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⚡ Bulk Schema Generation and Deployment Workflow

Overview Search Atlas lets you generate schema markup for multiple pages at once using the bulk schema workflow. If your generated schemas seem to disappear after selection, or you cannot find the deploy option, this article explains what is happening and how to complete the process. How Bulk Schema Generation Works The bulk schema workflow is designed to let you generate structured data for several pages in a single session. The general flow involves selecting pages, generating schema markup for each, and then deploying the generated schemas to make them live on your site. Generated schemas are held in a staging state after generation — they are not live until you explicitly deploy them. The most common point of confusion is this staging state: generated schemas do not disappear, but they move to a different view within the schema tool once processed, requiring a separate deploy step. Why Generated Schemas Appear to Disappear After bulk generation, schemas may no longer appear in the same view as unprocessed pages. This can make it look like the output has been lost. Common reasons this happens include: - Filter mismatch: The page list defaults to showing only pages without schema. Once schema is generated for a page, it moves out of that filtered view automatically. - Status view not switched: Generated schemas appear under a separate status — you need to change the status filter in the schema tool to see pages that already have schema generated. - Selection cleared: Navigating away from the page or refreshing the browser before deploying can clear your selection and may require you to regenerate. How to Locate Your Generated Schemas and Deploy Them Follow these steps to find your staged schemas and complete deployment: 1. Open the Schema Creator tool by clicking the apps-grid icon in the header, then selecting More Features → Schema Creator, and select your project. 2. Look for a status filter or tab selector near the top of the page list — common options include labels such as No Schema, Generated, and Deployed. 3. Switch the filter or tab to Generated (or the equivalent status for schemas that have been created but not yet deployed). Your previously generated schemas will appear here. 4. Select all the pages whose schemas you want to deploy by checking the checkboxes next to each page, or use the Select All option if available. 5. With pages selected, look for a Deploy button or a bulk action dropdown at the top of the list. Click it to push the generated schemas live to your site. 6. After deploying, switch the filter to Deployed to confirm the pages now show their schema as active. If you do not see a Generated status tab or the Deploy option does not appear after selecting pages, try clearing any active filters first, then repeat the selection. If the option is still missing, it is possible the generation step did not complete — return to the No Schema view, reselect the affected pages, and run bulk generation again before attempting to deploy. What to Do If You Are Still Stuck If you have followed the steps above and still cannot locate your generated schemas or complete deployment, our support team can walk you through the correct steps for your specific account and project setup. When reaching out, please have the following ready: - Your project name - The pages you attempted to generate schema for - The status tab or filter you currently see in the schema tool - A description of where in the workflow you got stuck (e.g., after generation, before deployment) - Any error messages or unexpected behavior you observed, including approximate timestamps If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Run a Local Taxi SEO Audit Yourself

🎯 What This Article Covers If you run a local taxi business and want to know what SEO improvements your website needs, you do not need to wait for a manual review. Search Atlas gives you the tools to run a full site audit, spot technical issues, and act on local SEO recommendations — all from your dashboard. 🛠️ Step 1: Create or Open Your OTTO Project Every audit starts with an OTTO SEO project tied to your website. 1. In the left sidebar, click OTTO SEO. 2. If you have not set up a project yet, click Create OTTO Project and follow the setup steps. 3. If your project already exists, select it from the list to open the Overview page. 🔎 Step 2: Run a Full Site Scan Once you are inside your OTTO project, trigger a fresh scan so the data reflects your current site state. 1. On the Overview page, click Scan in the top toolbar. 2. Wait for the scan to complete — this usually takes a few minutes depending on site size. 3. When finished, click Engage OTTO to let OTTO analyse the results and generate prioritised recommendations. Tip: If the scan appears to be missing or stuck, navigate to OTTO SEO → All Audits to confirm your audit project exists and is active. If it is not listed, re-create it from the OTTO SEO main page. 📊 Step 3: Review Your Audit Findings After the scan, go to OTTO SEO → All Audits to see a breakdown of every issue found on your site. For a local taxi business, pay close attention to: - Missing or duplicate title tags and meta descriptions — every page should have a unique, locally relevant title (e.g. "Airport Taxi in [City] | Your Brand"). - Thin or missing content — service area pages, fare pages, and booking pages need enough text to rank locally. - Broken links and crawl errors — these hurt trust signals and indexability. - Page speed issues — slow mobile load times directly impact local search rankings. - Missing structured data — LocalBusiness and TaxiService schema help Google understand your service type and location. 🗺️ Step 4: Check Local SEO Signals For local taxi businesses, visibility in map results and local SERPs matters as much as organic rankings. Use the following tools inside Search Atlas to check your local presence: - Navigate to OTTO SEO → Page Explorer to inspect individual pages and see which on-page elements are missing or weak. - Use the Brand Vault (accessible from OTTO SEO → Overview) to keep your business name, address, phone number (NAP), and service descriptions consistent across your site. Inconsistent NAP data is one of the top reasons local taxi sites underperform in map results. - Monitor crawl health regularly via OTTO SEO → Crawl Monitoring to catch new errors before they affect rankings. 💡 Step 5: Act on OTTO's Recommendations OTTO prioritises issues by impact so you know what to fix first. Work through the recommendations from the top of the list downward. For each issue, OTTO explains what the problem is, why it matters for local SEO, and what action to take. For a local taxi site, the highest-impact fixes are usually: 1. Adding or correcting location-specific title tags and headings. 2. Creating or expanding service area landing pages. 3. Fixing broken internal links. 4. Adding LocalBusiness structured data to your homepage and key service pages. 🔄 Step 6: Re-scan After Making Changes Once you have implemented fixes, return to OTTO SEO → Overview and click Scan again. This updates your audit score and confirms that the issues have been resolved. Repeat this process regularly — monthly scans are a good baseline for an active local business. ❓ Still Have Questions? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🚀 Deploy All Button: Prerequisites and Correct Workflow

🔍 Overview The Deploy All button in Site Audit lets you publish AI-generated SEO suggestions across your entire site in one click. However, it only deploys suggestions that have already been generated by the AI. If you skip the generation step, Deploy All will only process the suggestions that exist at that moment — leaving the rest untouched. This article walks you through the correct end-to-end workflow so every suggestion is generated and deployed successfully. ⚠️ Why Only Some Suggestions Deployed If you added a new domain, clicked Deploy All, and only a fraction of your suggestions deployed (for example, 10 out of 55 title tags), this is almost always because the AI had only generated suggestions for a subset of your pages or categories at that point. Deploy All does not trigger AI generation — it deploys whatever suggestions already exist. You must complete the AI generation step first for every category you want to deploy. ✅ The Correct Workflow: Step by Step 1. Add your domain. In the left sidebar, go to OTTO SEO → SEO Automation (URL: /seo-automation-v3). Add your domain if you have not done so already and wait for the initial crawl to complete. 2. Open Site Audit. Once the crawl finishes, navigate to the Site Audit section for your domain. You will see suggestion categories such as Title Tags, Meta Descriptions, Headings, and others. 3. Generate AI suggestions for each category. This is the mandatory prerequisite step. For each category you want to deploy: - Open the category (for example, Title Tags). - Click the Generate or Generate AI Suggestions button for that category. - Wait for the AI to finish generating suggestions for all pages in that category. A progress indicator will confirm when generation is complete. - Repeat this process for every other category you want to include — Meta Descriptions, Headings, and so on. 4. Review generated suggestions (recommended). Before deploying, scan through the AI-generated suggestions to confirm they meet your expectations. You can edit any individual suggestion directly in the interface. 5. Click Deploy All. Once AI suggestions have been generated across all desired categories, click Deploy All. The button will now process and publish every available suggestion across your site. 💡 Key Things to Know - Deploy All only deploys what already exists. If a category has no generated suggestions, those pages are skipped entirely. - Generation takes time. For large sites with many pages, AI generation can take several minutes per category. Do not click Deploy All until all generation tasks show as complete. - You can deploy one category at a time. If you prefer more control, generate suggestions for a single category and use that category's individual deploy option before moving to the next. - Re-running generation is safe. If you added new pages or want fresh suggestions, you can re-generate a category at any time. Existing deployed suggestions will not be overwritten unless you deploy again after regenerating. - Newly added domains start with zero suggestions. Every time you connect a new domain, the AI has not yet run. You must manually trigger generation for each category before Deploy All will have anything to publish. 🗂️ Quick Reference: Generation Before Deployment - Step 1 — Crawl complete? Yes → proceed. No → wait for the crawl to finish. - Step 2 — AI suggestions generated for all categories? Yes → proceed. No → open each category and click Generate. - Step 3 — Ready to deploy? Click Deploy All to publish every generated suggestion at once. 🆘 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 Your Crawl Distribution Dropped Month-Over-Month

📊 What Crawl Distribution Means Crawl distribution shows how many of your site's URLs were crawled and processed within a given time period. The number you see for a month reflects activity inside that specific date range. Because it is tied to a window of time, the figure naturally rises and falls as crawl activity changes from one month to the next. A drop, such as going from 7,000 in May to 1,000 in June, does not automatically mean something is broken. In most cases there is a clear, expected reason. This article walks you through the common causes and how to check each one. 🗓️ Reason 1: The Month Is Still In Progress This is the most common cause. If you compare a completed month against one that is only partway through, the current month will always look smaller. May had a full set of days to accumulate crawls, while June may still be gathering data. - A figure of 1,000 mid-June compared to 7,000 for all of May is usually on track. - Wait until the month closes before comparing totals side by side. 🔁 Reason 2: Crawl Frequency and Scheduling Crawls run on a schedule rather than continuously. The number of crawls in a period depends on how often your project is set to crawl and when the last crawl completed. If a large crawl finished late in May, that volume is counted in May, leaving June lower until the next crawl runs. - Check when your most recent crawl completed. - Confirm whether a scheduled crawl is still pending for the current month. ⚙️ Reason 3: Project or Setting Changes Changes to your project configuration can affect how many URLs are crawled. Review whether any of the following changed recently: - Crawl limits were lowered, reducing the number of URLs processed. - URL scope or filters were narrowed, excluding pages that were previously included. - Sitemaps or seed URLs were updated or removed. - The project was paused or its schedule was adjusted. 📦 Reason 4: Your Monthly Crawled Pages Budget Was Reached Your plan includes a Number of Monthly Crawled Pages quota. Once the pages crawled in a month reach this budget, further crawling for that period stops until the quota resets at the start of the next month. If May consumed most of the budget late in the month, June can start lower until the allowance refreshes. - Look for the Crawl Budget Depletion Warning in the platform, which indicates the monthly page budget has been used up. - Compare the pages crawled against your plan's monthly crawled pages allowance to see if the quota was the limiting factor. - Note that the depletion warning appears once the budget is already used up. A proactive warning that flags when your crawl settings would exceed the monthly page budget before a crawl runs is currently in development and not yet available. 🌐 Reason 5: Changes On Your Website Sometimes the drop reflects real changes on your site rather than the platform. Consider whether any of these apply: - Pages were removed, redirected, or returned errors, leaving fewer URLs to crawl. - Your robots.txt file or meta directives now block sections of the site. - Server slowdowns or downtime prevented pages from being reached during the crawl. 🔍 How to Check Your Crawl Data Follow these steps to confirm what is happening: 1. Open the affected project in your dashboard. 2. Set the date range to a full, completed month so you compare equal time periods. 3. Review the crawl history to see when the last crawl ran and how many URLs it covered. 4. Check your crawl settings for recent changes to limits, scope, or scheduling. 5. Check whether your monthly crawled pages budget was reached, including any crawl budget depletion warning. 6. Verify your robots.txt and sitemap are accessible and unchanged. ✅ When the Drop Is Expected A lower number is normal when the current month is incomplete, when a large crawl landed in the prior month, when your monthly crawled pages budget was reached, or when you intentionally reduced crawl scope or limits. In these cases no action is needed, and numbers typically even out once the month completes, the quota resets, and the next crawl runs.

🔍 Diagnose Canonical Tags and Google Indexing Issues

🧭 Overview If Google is not indexing your site, a misconfigured or missing canonical tag is one of the most common culprits. Canonical tags tell Google which version of a page is the preferred one for indexing. When they are wrong, Google may skip your pages entirely or index the wrong URL. Search Atlas provides tools to help you diagnose these issues — you do not need to wait on Google to figure out what is going wrong. 🚦 Common Canonical Tag Problems That Block Indexing - Self-referencing canonical missing: A page has no canonical tag, leaving Google to guess the preferred URL. - Canonical points to a different page: Google follows the canonical and ignores the original page entirely. - Canonical points to a non-indexable URL: The target URL is blocked by robots.txt, returns a redirect, or returns a non-200 status code. - Conflicting canonicals: The HTML canonical and the HTTP header canonical disagree. - Paginated pages with incorrect canonicals: All paginated URLs point to page one, signalling duplicate content to Google. 🛠️ How to Start Diagnosing Canonical and Indexing Issues in Search Atlas Search Atlas includes site auditing and technical SEO tools that can surface canonical tag problems across your site. Because the exact navigation steps and feature names can vary as the platform is updated, we recommend the following approach: 1. Log in to your Search Atlas account and open the project for the site you want to diagnose. 2. Look for a Site Audit or Technical SEO section within your project dashboard — this is where crawl-based issue reports are typically found. 3. Run or review the latest site crawl for your domain. The crawl analyses your pages similarly to how Google crawls them and surfaces technical issues including canonical tag errors. 4. Within the audit results, look for canonical-related issues such as missing canonical tags, canonicals pointing to redirected or non-indexable URLs, conflicting canonical signals, or non-self-referencing canonicals. 5. Prioritise fixing any canonical tags that point to pages blocked by robots.txt, returning error status codes, or conflicting with HTTP header canonicals, as these are most likely to directly suppress indexing. 📋 Common Canonical Issues to Look For - Pages missing a canonical tag entirely - Canonical tags pointing to redirected URLs (3xx chains) - Canonical tags pointing to pages that return a 4xx or 5xx status - Canonical tags pointing to pages blocked in robots.txt - Pages with multiple canonical tags (conflicting signals) - Canonical URLs that do not match the page's own URL (non-self-referencing) 🔗 Next Steps After Identifying Issues Once you have identified canonical problems, work through them by correcting the canonical tag values in your CMS or page templates. After making changes, re-run the site audit to confirm the issues have been resolved. If Google is still not indexing pages after canonical issues are fixed, consider also reviewing your robots.txt configuration and checking whether the affected URLs are being submitted in your sitemap. If you are unsure which specific tool or report within Search Atlas applies to your site's situation, a member of our team can point you in the right direction. Have your project name, the affected URLs, and any error details ready when you reach out. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

How to Delete Frozen OTTO and Site Auditor Projects

If your account was downgraded or a subscription lapsed, one or more of your OTTO or Site Auditor projects may appear as frozen. These projects still occupy a plan slot but cannot be used. Deleting them frees those slots so you can create new, active projects. ❄️ What Is a Frozen Project? A project becomes frozen when your current plan no longer includes enough slots to cover all existing projects — typically after a downgrade or cancellation. Frozen projects remain visible in your dashboard but are completely inactive. They count against your slot limit and will not unfreeze on their own. Note: In some cases a frozen OTTO project may also be in a deep-frozen state — for example, if it is still linked to an active OTTO client. Deep-frozen projects cannot be deleted through the dashboard at this time. If you attempt to delete a frozen project and receive an error, or if the project does not have a delete option, please contact support via the chat widget (see below). 🗑️ How to Delete a Frozen OTTO Project 1. Open OTTO SEO from the left sidebar in your Search Atlas dashboard (Left sidebar → OTTO SEO → All Sites). 2. Locate the frozen project in your OTTO project list. 3. Click the three-dot menu (⋮) on the project card. 4. Select Delete Project or Remove Site. 5. Confirm the deletion when prompted. After deletion, the freed slot may take up to 24 hours to reflect in your quota count. If your slot count does not update right away, refresh the page and allow up to 24 hours for the change to fully process. 🔍 How to Delete a Frozen Site Auditor Project 1. Go to Site Auditor in the left sidebar (Left sidebar → OTTO SEO → All Sites). 2. Find the frozen project in your project list. 3. Click the kebab menu (⋮) or the project settings icon. 4. Select Delete or Remove. 5. Confirm the deletion when prompted. After deletion, the freed slot may take up to 24 hours to reflect in your quota count. ⚠️ Important: What Happens After Deletion - Deletion is permanent. All audit history, OTTO deployments, suggestions, and configuration are gone and cannot be restored. - OTTO changes on your live website are not automatically removed. If OTTO deployed schema markup or NLP modules to your site, those changes remain live until you remove them manually — by uninstalling the WordPress plugin or deleting the OTTO JavaScript snippet from your site's code. - Frozen projects will not unfreeze on their own. To keep a project without deleting it, you must upgrade to a plan that supports the additional slot. - Slot counts may take up to 24 hours to update in your dashboard after deletion. This is a known platform delay; a page refresh may show the updated count sooner, but full propagation can take up to 24 hours. - Some frozen projects cannot be deleted from the dashboard. If a frozen project is linked to an active OTTO client (deep-frozen state), the delete option may be unavailable or return an error. Contact our support team using the chat widget below to have the slot manually freed. 💬 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.

🔍 URL Indexer: Why Your Pages Are Not Indexed Yet (And What Google Actually Controls)

✅ What the URL Indexer does — and doesn't do The Search Atlas URL Indexer submits your pages to Google's official Indexing API, which signals to Google that a URL is ready to be crawled. This is the fastest official method to request indexing. However, Google makes the final decision on when and whether to index any page. 🤔 Why your page may not be indexed after submission - Content quality — thin, duplicate, or low-value content is often not indexed - Crawlability — the page must be accessible to Googlebot (check robots.txt and noindex tags) - Domain authority — new or low-authority sites get indexed more slowly - Canonical structure — if a page has a canonical tag pointing elsewhere, Google may skip it ⏱️ Realistic indexing timelines - High-authority sites: hours to 24 hours after submission - Medium-authority sites: 1-4 days - New or low-authority sites: 4-14 days, sometimes longer 🔄 If the Indexer shows "Not Indexed" but the page appears in Google The Indexer's indexation status is refreshed on a periodic cycle (status checks run roughly once per hour), so a recently indexed page can still show as Not Indexed until the next refresh. In some past cases the status was also reported prematurely or pulled from stale API data before a submission had fully finalized, which caused already-indexed URLs to be mislabeled — these reporting issues have since been fixed. If a page shows Not Indexed in the URL Indexer, confirm the true status in Google Search Console > URL Inspection, which reflects Google's own index. If GSC shows the page as indexed, treat the Indexer status as out of date and allow it to refresh. If submissions appear to never process or trigger indexing at all, this is a separate known issue under review — contact Search Atlas support so your case can be checked. 🚀 How to improve your chances of indexing 1. Use Google Search Console > URL Inspection to check for crawl or indexing issues 2. Ensure the page has unique, substantive content 3. Add the page to your XML sitemap and submit the sitemap in GSC 4. Build internal links to the page from already-indexed pages

🔄 How to Initiate a Website Recrawl and Reprocess

This article explains how to trigger a fresh crawl of your website and manually reprocess its data inside Search Atlas — so that any recent changes to your site's content, structure, or metadata are picked up and reflected in your reports and tools. 📍 Where to Find It Navigate to OTTO SEO → Site Audit → Overview (Website Overview) using the left sidebar. Select the website you want to recrawl from your list of projects. 🛠️ Step-by-Step 1. Open OTTO SEO → Site Audit → Overview (Website Overview) from the left sidebar and select the target website. 2. Locate the crawl or site settings area within your selected project. Look for the button labeled Recrawl Site and click it to initiate a fresh crawl of your site. 3. Once the crawl has completed (you will typically see a progress indicator or a completion status message), look for a Reprocess or Manual Reprocess option in the same settings area. Click it to trigger the reprocessing of the newly crawled data. 4. If both actions are available as separate buttons, complete the recrawl first and wait for it to finish before initiating the manual reprocess — running them in sequence ensures the reprocess works on the most up-to-date crawl data. ✅ How to Confirm It Worked After initiating the recrawl and reprocess, confirm success by checking the following: - The crawl status indicator should update from In Progress to Completed (or a similar finished state) — this confirms the recrawl finished successfully. - The Last Crawled or Last Updated timestamp on your website should reflect today's date and time. - Navigate to any report or tool that pulls data from this site (such as site audit results or page-level data) and verify that recent changes you made to your site — such as new pages, updated titles, or fixed issues — are now appearing correctly. - If a reprocess was completed, previously flagged issues that you have since fixed should no longer appear, and any newly added content should now be visible in your data. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. Additional Notes If you cannot locate an option to trigger a recrawl or reprocess, a member of our support team can initiate a backend reprocess on your behalf. Contact via chat widget and type 'human teammate' to be connected.

🔄 Update OTTO Sitemap and Robots.txt After Deleting URLs

🗺️ Overview When you delete URLs from OTTO, three things need to happen in the correct order: your sitemap and robots.txt must reflect the changes, Google Search Console must be notified, and OTTO must complete a new analysis cycle to recognise the updated state of your site. This article walks you through each step. ✅ Step 1: Confirm Your Sitemap and Robots.txt Are Updated Before touching Google Search Console, verify that the files on your server already reflect the deletions. - Sitemap: Open your sitemap URL (typically yourdomain.com/sitemap.xml) and confirm the deleted URLs no longer appear. - Robots.txt: Open yourdomain.com/robots.txt and check that you have not accidentally blocked pages you still want indexed. If OTTO manages your robots.txt, any rules you applied inside OTTO should already be saved. If you edited the file manually, make sure the file is live on your server before continuing. 🤖 Step 2: Configure the SearchAtlasBot User-Agent in Robots.txt OTTO uses its own crawler called SearchAtlasBot to audit your site. For OTTO to crawl and analyse your pages accurately, this user-agent must not be blocked in your robots.txt file. Check your robots.txt for any Disallow rules that apply to SearchAtlasBot or to all bots via a wildcard (User-agent: *). A correctly configured entry looks like this: - User-agent: SearchAtlasBot - Disallow: (leave blank to allow full access) If SearchAtlasBot is blocked, OTTO will not be able to verify that your deleted pages are gone, and its analysis will not update correctly. Save and publish the robots.txt file once you have confirmed this entry. 📡 Step 3: Submit Your Updated Sitemap to Google Search Console 1. Log in to Google Search Console and select the property that matches your domain. 2. In the left sidebar, click Sitemaps under the Indexing section. 3. If your sitemap is already listed, click on it and then click Resubmit. If it is not listed, enter your sitemap URL in the Add a new sitemap field and click Submit. 4. Google will queue your sitemap for recrawling. The status will show as Success once it has been read. 🔍 Step 4: Request a URL Inspection and Recrawl in Google Search Console Submitting the sitemap tells Google your site has changed, but for priority pages you want deindexed quickly, use the URL Inspection tool to speed up the process. 1. In Google Search Console, paste a deleted URL into the URL Inspection search bar at the top and press Enter. 2. Once the inspection loads, click Request Indexing. 3. Google will add the URL to its crawl queue. This typically signals Google to check whether the page still exists and update its index accordingly. Repeat this for any high-priority deleted URLs. Note that Google processes these requests within hours to a few days, depending on your site's crawl budget and authority. ⏱️ Step 5: Understand OTTO Recrawl Timing and the Next Analysis Cycle After you update your sitemap, robots.txt, and Google Search Console, OTTO needs to run a new analysis cycle before it reflects the changes in your dashboard. - OTTO triggers a new crawl and analysis based on a scheduled cycle. Most sites are re-analysed within 24 to 48 hours after changes are detected or manually triggered. - If you want to prompt OTTO to re-analyse sooner, open your OTTO project, navigate to OTTO SEO → Site Audit → Overview (Website Overview), and use the Recrawl Site button. - Until the new cycle completes, previously deleted URLs may still appear in OTTO's issue list. This is expected behaviour and will resolve once the crawl finishes. 🔎 Step 6: Verify Page Status Using Page Explorer Once OTTO has completed its next analysis cycle, use the Page Explorer tool to confirm that your deleted URLs are no longer tracked as active pages. 1. Inside your OTTO project, open the Page Explorer tab. 2. Search for one of the deleted URLs using the search or filter bar. 3. Check the page's status. A deleted page should show a 404 or removed status, or it may no longer appear in the list at all. 4. If a deleted URL still shows as 200 OK, the page may still be live on your server. Double-check that the deletion was fully published and that any caching layers (CDN, server cache) have been cleared. Page Explorer gives you a ground-truth view of what OTTO's crawler sees, making it the most reliable way to confirm that your deletions have been processed correctly end to end. 📋 Quick Reference: Full Workflow Checklist - Confirm deleted URLs are removed from your live sitemap. - Verify SearchAtlasBot is not blocked in robots.txt. - Resubmit or submit your sitemap in Google Search Console. - Use URL Inspection to request recrawl for priority deleted URLs. - Wait 24–48 hours for OTTO's next analysis cycle to complete. - Check Page Explorer to confirm deleted pages show a 404 or removed status. 💬 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.

☁️ Cloud Stacks Indexation and Indexing Tool Guide

🔍 Understanding Cloud Stack Indexation Cloud stacks are networks of web 2.0 properties built to support your link-building strategy. While Search Atlas creates and publishes these stacks on your behalf, indexation is not guaranteed — it depends on how quickly third-party search engines (like Google) discover and crawl the URLs. In some cases, this process can take weeks or even several months. This is normal behaviour and is not a sign that something has gone wrong with your cloud stack build. However, there are steps you can take to speed up and improve indexation rates. ⚙️ Why Cloud Stacks May Not Get Indexed - Crawl delay: Search engines prioritise well-established domains. New web 2.0 properties are often crawled less frequently. - No inbound signals: Pages with no external links or traffic signals are less likely to be discovered quickly. - Platform restrictions: Some third-party platforms used in cloud stacks limit search engine access at times. - Volume: Large stacks contain many URLs — indexation naturally takes longer across a high number of pages. 🛠️ How to Use the URL Indexer Tool Search Atlas includes a built-in URL Indexer tool specifically designed to help push your cloud stack URLs to search engines faster. Follow these steps to submit your URLs for indexing: 1. Log in to your Search Atlas account. 2. In the left sidebar, navigate to Authority → Indexer (URL Indexer). 3. Locate your cloud stack URLs. You can find these under Authority → Cloud Stacks — open the relevant stack and copy the list of generated URLs. 4. Paste your URLs into the URL Indexer input field. You can submit multiple URLs at once. 5. Click Index URLs to send the URLs to search engine crawlers. After submission, allow 7–14 days for search engines to process the request. Indexation is not instant, but submitting through the URL Indexer significantly improves your chances. 📊 Checking Your Indexation Progress To verify whether your cloud stack URLs are being indexed, use Google Search Console (if the properties are connected) or perform a manual check by entering site:yourcloudstackurl.com in Google Search. Repeat this check weekly after submitting through the URL Indexer. Keep in mind: - Not every URL in a large stack will index — a 40–70% indexation rate is considered healthy and normal. - Resubmitting unindexed URLs through the URL Indexer after 2–3 weeks can improve results. - Avoid submitting the same URLs more than once every two weeks, as over-submitting can be counterproductive. 💡 Best Practices to Improve Indexation - Build links to your cloud stacks: Sharing cloud stack URLs on social media, forums, or other indexed pages gives search engines a reason to crawl them. - Use the URL Indexer consistently: Make indexer submissions part of your regular workflow after each new cloud stack is created. - Allow adequate time: Set realistic expectations — full indexation of a large stack can take 2–4 months even with active submission. - Keep your stacks active: Cloud stack properties that receive occasional visits and signals tend to retain indexation better over time. 🚀 Where to Find Your Tools All the tools you need are located in the Authority section of your Search Atlas account: - Left sidebar → Authority → Cloud Stacks — view and manage your existing stacks and access their URLs. - Left sidebar → Authority → Indexer (URL Indexer) — submit URLs to search engines for faster indexation. 🙋 Need More Help? If you have submitted your URLs through the Indexer, waited the recommended time, and are still seeing very low indexation rates, our team is happy to review your specific stack. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Log File Analysis for SEO: A Complete Guide

What Is a Log File? A log file is a computer-generated record that automatically captures and stores chronological information about events and transactions occurring on a server. Think of it as a digital audit trail — every time something interacts with your website, the server writes it down. In the context of SEO, the log files that matter most are web server log files: records of every single request made to your website, whether from a real user, a search engine bot, or any other automated agent. What Data Does a Server Log File Contain? Each line in a server log typically records the following data points: - IP Addresses — the source of each request, which lets you distinguish human visitors from crawlers. - User Agents — identifies the browser, device, or bot making the request. - Requested URLs — the exact pages, images, scripts, and other assets accessed. - Timestamps — the date and time of each request, enabling crawl pattern analysis over time. - HTTP Status Codes — the server's response to each request (for example, success, redirect, not found, or server error). - Referrers — the source that directed a request to a given URL, useful for tracking traffic origins and internal linking patterns. Log files are only retained for a limited time on most servers, so regular access and archiving is recommended to avoid losing historical data. What Is Log File Analysis? Log file analysis is the structured process of downloading, reviewing, and interpreting server logs to surface technical SEO problems, crawling inefficiencies, and performance issues. Unlike data from third-party tools, log files are first-party data — raw and unfiltered. They capture activity from all search engines simultaneously and do not rely on JavaScript rendering or sampling. Why Is Log File Analysis Important for SEO? Log file analysis gives you a direct view of how search engines experience your website. Core benefits include: - Crawl Pattern Discovery — understand which pages search engines visit most and least frequently. - Crawl Budget Optimization — identify low-value pages that consume crawler resources without contributing to rankings. - Technical Issue Detection — surface broken links, redirect chains, server errors, and other problems that block search engines from reaching important pages. - Orphan Page Identification — find pages that exist on your server but are not linked to from anywhere on your site. How to Perform Log File Analysis Follow these general steps to analyze your server log files for SEO insights: 1. Obtain your log files. Download your server log files from your hosting control panel (e.g., cPanel, Plesk) or request them from your hosting provider. Common formats include Apache access logs and Nginx access logs. 2. Filter for search engine bots. Isolate requests made by crawler user agents such as Googlebot, Bingbot, and others by filtering on the User Agent field. This separates bot activity from human traffic. 3. Identify crawl frequency patterns. Review which URLs are being crawled most and least often. Pages crawled rarely or never may need better internal linking or inclusion in your sitemap. 4. Audit HTTP status codes. Look for pages returning 404 (not found), 500 (server error), or long redirect chains (301/302). These waste crawl budget and should be resolved. 5. Spot orphan pages. Cross-reference crawled URLs against your sitemap and internal link structure. URLs that appear in logs but nowhere in your site architecture are orphan pages that may need linking or removal. 6. Prioritize fixes. Use your findings to prioritize technical SEO work — focus first on high-value pages that are being crawled infrequently or returning errors. If you use Search Atlas and have questions about how its tools support log file analysis or technical SEO workflows, our support team can point you to the right resources. If you need further assistance, open 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 Loading States and Timeline

🔍 Overview When you add a new website to OTTO (found in the left sidebar under OTTO SEO → All Sites (SEO Automation)), you may notice that the dashboard shows an infinite loading indicator or no status information at all. This is expected behavior — it means OTTO is actively crawling your site for the first time. This article explains what is happening, how long it takes, and what to do if the loading state persists. ⚙️ Why You See an Infinite Loading State After adding a domain to OTTO, the platform immediately begins a full site audit. During this initial crawl, OTTO has not yet collected enough data to display recommendations, scores, or status indicators. As a result, the dashboard will show a spinning or infinite loading state instead of populated metrics. This loading state does not indicate an error with your account, a failed pixel installation, or a problem with your domain. It simply means the audit is in progress and data is being gathered in the background. 🕐 Expected Timeline for Initial Site Audit The initial crawl typically completes within 24 hours of adding your site. The exact duration can vary depending on: - The total number of pages on your website - Your site's server response speed - Current crawl queue volume across the platform Once the audit is complete, your OTTO dashboard will automatically populate with findings, recommendations, and your site's SEO health data. No action is needed on your part while the crawl is running. 📊 How to Check Your Audit Progress You can check whether your audit is still in progress by following these steps: 1. Click OTTO SEO → All Sites (SEO Automation) in the left sidebar. 2. Locate your domain in the site list. 3. If no data has appeared yet, the audit is still in its early crawling phase. Return after 24 hours to check again. 🛠️ What to Do If Loading Persists After 24 Hours If more than 24 hours have passed and your OTTO dashboard is still loading with no data, try the following steps: 1. Refresh your browser and clear your browser cache, then reload the OTTO SEO → All Sites (SEO Automation) section. 2. Confirm that the domain you added is publicly accessible and not behind a login or maintenance page, as restricted pages can prevent the crawl from completing. 3. Check that you entered the correct domain URL when adding the site — a typo or incorrect format can cause the audit to stall. 4. If none of the above resolves the issue, contact our support team and have the following information ready: your project or domain name, the date and time you added the site, and a description of what you currently see on the dashboard. 🔗 OTTO Pixel Installation and Site Audit The OTTO pixel and the site audit are two separate systems. A loading audit does not mean your pixel is missing or broken. If you have concerns about whether your pixel is correctly installed while the audit is running, navigate to the OTTO SEO → All Sites (SEO Automation) section in the left sidebar, select your domain, and review the available setup or configuration options for your pixel tracking code. If you are unsure whether your pixel is active, wait until the initial 24-hour audit period completes, as pixel-related information may become more visible once audit data is populated. If you need further assistance, open 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 Install and Use the Search Engine Audit Widget

Every website visitor is a potential opportunity, but without the right system in place, most of them leave unnoticed. The Search Engine Audit Widget transforms passive traffic into qualified SEO leads by offering instant value in exchange for contact information. In just a few steps, you can activate a fully branded audit experience that captures, stores, and routes leads directly into your workflow. 🎯 What Is the Search Engine Audit Widget? The widget allows visitors to enter their website URL, receive an instant SEO audit, and submit their contact details. When they do, their information is captured inside your dashboard. 🛠 Step 1 — Where to Find the Widget Accessing Agency Hub from the dashboard header When you log into Search Atlas, you land on the Home dashboard: a dark background, a left vertical sidebar navigation, your profile in the top right (CSM Team dropdown), and a grid icon (feature launcher) near the top right. In the top right corner, click the grid icon (9-dot icon), in the same icon group as the Atlas Agent button and the credits display. A slide-out panel titled More Features appears from the right side with multiple feature tiles. More Features panel with Agency Whitelabel option In the More Features panel, locate Agency Hub (purple flag icon) and click it. This opens the White Label Setup page. Inside White Label Setup, a blue notification banner reads: Activate Your Whitelabel Agency to Access Advanced Settings. Below that is a horizontal tab navigation: White Label Setup, Settings, Site Analysis Lead Capture Widget, Affiliate Link, and Join SEOTheory Community (Logo). Site Analysis Lead Capture Widget tab Click the third tab, Site Analysis Lead Capture Widget. It becomes highlighted with a blue underline, opening the widget configuration page. 🧭 What You See on the Widget Configuration Page The page is organized into sections: - Configure and Test the Widget — placeholder and button text fields, background and font color selectors, a live preview box, and an Analyze My Site test button, so you can customize how the widget looks before installing it. - Install the Widget — copy the snippet and paste it as HTML using the Copy Snippet to Clipboard button. This is the actual installation code. - Add Custom HTML (Optional) — a toggle to add HTML to the top or bottom of the report, used for injecting custom branding or messaging into generated reports. - Integrations (Optional) — a table listing Application, Webhook, and Actions, with an Add Webhook button for pushing captured leads to external systems. - Leads Captured — a table at the bottom of the page showing Domain, Email, Phone Number, Company, and Time Stamp for every lead captured in real time. Full path: Header 'More Features' (grid icon) → Agency Hub → White Label Setup → Site Analysis Lead Capture Widget tab (Logo page, /agency-settings). 💻 Step 2 — How to Install the Widget on Your Website Inside the widget settings, you'll find the embed code. To install it, copy the widget script and paste it into your website's HTML, either before the closing body tag or inside your site builder's custom code section. Once installed, the widget will appear on your site and start collecting leads automatically. 📥 Step 3 — Where Leads Go When someone completes the audit, their domain, email, phone number, company name, and timestamp are automatically stored in Agency Settings → Site Analysis Lead Capture Widget → Leads Captured. No manual configuration is required. 🔗 Optional: Connect a Webhook If you want leads sent to your CRM, scroll to Integrations, click + Add Webhook, and connect your automation platform. Leads can then trigger email sequences, CRM pipelines, Slack alerts, and sales notifications. 🚀 Best Practice After a lead submits, run a branded report, send the audit immediately, and follow up within 5–15 minutes. Speed dramatically increases close rate. Once installed, the Search Engine Audit Widget works quietly in the background, analyzing domains, capturing contact details, and feeding your pipeline in real time. Combined with automated reporting and webhook integrations, it becomes a scalable lead generation engine. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⏱️ Manual Site Crawl Duration and Speed Settings Explained

🔍 Overview When you trigger a manual site crawl in Search Atlas, the process can take anywhere from a few minutes to up to 24 hours, depending on your site's size and server conditions. This article explains what to expect, what the crawl speed setting actually does, and why your crawl duration is influenced by factors beyond that setting. ⏳ How Long Does a Manual Crawl Take? There is no single fixed duration for a manual crawl. The time it takes depends on several variables, but the ranges below give you a reliable reference point: - Small sites (under 500 pages): Typically completes within 15–60 minutes. - Medium sites (500–10,000 pages): Usually takes 1–6 hours. - Large sites (10,000+ pages): Can take anywhere from 6 to 24 hours. If your crawl has been showing as loading for several hours but falls within the range above for your site size, this is expected behaviour. A crawl is only considered stuck if it has exceeded 24 hours without completing. ⚙️ What Does the Crawl Speed Setting Actually Control? The crawl speed setting controls the rate at which the crawler sends requests to your server — measured in requests per second. In simple terms, it determines how aggressively the crawler asks your site for pages. - Lower speed: Fewer requests per second, which is gentler on your server and reduces the risk of triggering rate limits or temporary blocks. - Higher speed: More requests per second, which can help the crawler move through pages faster — but only when your server can respond quickly enough to keep up. Think of crawl speed as setting the maximum pace the crawler tries to move at — not the pace it will always achieve. 🚧 Why Doesn't Crawl Speed Guarantee Total Duration? Even with the highest crawl speed selected, your total crawl time can still be long. This is because crawl speed only controls one part of the process. Several server-side and backend factors determine the actual time to completion: - Server response times: If your web server is slow to respond to requests — due to hosting limitations, high traffic, or page complexity — the crawler must wait before it can move on. No speed setting overrides this. - Rate limiting and throttling: Some servers automatically slow down or temporarily block rapid requests. When this happens, the crawler backs off to avoid being blocked, regardless of your speed setting. - Redirect chains and crawl depth: Sites with deep page hierarchies or long redirect chains require more individual requests to fully map, extending total time. - Backend processing time: After the crawler collects raw data, Search Atlas processes and analyses that data on the backend. This processing phase runs after the crawl itself and adds to the total time before results appear. - Total number of unique URLs: The more unique pages discovered during a crawl, the longer the full process takes, independent of speed. 📋 What to Do If Your Crawl Seems Stuck 1. Check how long the crawl has been running. If it is under 24 hours, allow it to continue — this is within the expected window. 2. Verify that the site being crawled is publicly accessible and not returning widespread errors (such as 5xx server errors), which can cause the crawler to stall. 3. If the crawl has exceeded 24 hours with no change in status, try cancelling and restarting the crawl from OTTO SEO → Site Audit → Crawl Monitoring. 4. Consider lowering the crawl speed setting if your server has limited capacity — this can prevent throttling and actually result in a more stable, complete crawl. 💡 Tips for Faster, More Reliable Crawls - Schedule manual crawls during low-traffic periods on your site so the server can respond more quickly. - Use a moderate crawl speed if you are on shared hosting — very high speeds can trigger server-side blocking that slows the overall crawl. - Ensure your robots.txt file is not inadvertently blocking the Search Atlas crawler from key sections of your site. - If you only need data for a specific section, consider whether a targeted crawl of a subdirectory is more efficient than a full-site crawl. 🙋 Need Further 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.

🔍 URL Pattern Exclusion and Subdomain Handling Explained

🗺️ Overview Search Atlas gives you control over which URLs appear in your dashboards and reports. You can manually exclude specific URL patterns, and certain subdomains are handled automatically by the platform. This article explains both features so your data stays clean and relevant. 🚫 Excluding Specific URL Patterns If you want to remove certain URLs or page types from your Search Atlas dashboards and reports, you can set up URL pattern exclusions. Common use cases include excluding thank-you pages, admin paths, staging directories, or any URLs that should not factor into your SEO analysis. To exclude URL patterns from your reports, follow these steps: 1. Log in to your Search Atlas account and navigate to the relevant project or dashboard. 2. Open the Settings for that project. 3. Locate the URL Exclusions or Filtered URLs section. 4. Enter the URL pattern you want to exclude. You can use partial strings (for example, /thank-you/ or /staging/) to match multiple URLs at once. 5. Save your changes. The exclusion will apply to new data refreshes going forward. Note: URL exclusions affect how data is displayed in your dashboards. They do not prevent Search Atlas crawlers from visiting those URLs — they only filter the URLs out of your reports and metrics. 🌐 How Subdomains Are Handled Search Atlas treats subdomains as separate entities from the root domain by default. This means blog.yourdomain.com and yourdomain.com are tracked independently unless you configure them to be grouped together. Here is what you need to know about subdomain behaviour: - Automatic separation: Each subdomain you add as a project is tracked on its own. Metrics such as keyword rankings, backlinks, and site health scores are not combined with the root domain automatically. - Search Atlas platform subdomains: Internal Search Atlas subdomains (for example, tool pages and application subdomains on searchatlas.com) are excluded from toolbar overlays and reporting features to avoid interference with your workflow. - Robots.txt and crawlability: If you manage subdomain sites, make sure your robots.txt file is correctly configured. Misconfigured robots.txt files on subdomains can allow unintended crawling by search engines, which may affect your SEO data. Search Atlas surfaces crawl issues like this in your Site Audit reports. - www vs. non-www: Search Atlas recognises www.yourdomain.com and yourdomain.com as different URLs. When connecting your site, use the version that matches your canonical domain consistently to avoid data discrepancies. ⚙️ Grouping Subdomains Under One Project If you want to view a root domain and its subdomains together in a single project, you can add multiple properties to one project using the Add Property option within your project settings. This lets you monitor combined traffic and performance without losing the ability to filter by individual subdomain when needed. 🛠️ Troubleshooting Common Issues Use the guidance below if you run into problems related to URL exclusions or subdomain handling: - Excluded URLs still appearing in reports: Exclusions apply to new data after you save them. Historical data already in your dashboard may still show the excluded URLs until the next data refresh cycle. - Subdomain data not showing up: Confirm the subdomain has been added as a tracked property in your project. Also verify that the subdomain is accessible and not blocked by robots.txt or a login wall. - www subdomain causing connection errors: If you experience issues connecting your site when your URL includes www, ensure the URL entered in Search Atlas exactly matches your WordPress or CMS home URL setting, including the www prefix. - Toolbar appearing on unintended pages: The Search Atlas SEO Toolbar is designed to exclude platform pages automatically. If the toolbar appears somewhere unexpected, refreshing the page or clearing your browser cache usually resolves this. 💡 Best Practices - Decide on a consistent URL format (www or non-www, HTTP or HTTPS) before setting up your project to prevent duplicate tracking. - Review your URL exclusion list periodically to make sure it reflects your current site structure. - Use the Site Audit tool to check for robots.txt issues on all subdomains you manage. - When in doubt about whether a subdomain should be a separate project or grouped with the root domain, consider your reporting goals — separate projects give more granular data, while grouped properties give a combined 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.

🛠️ Using Search Atlas Tools on a Staging Subdomain

🔍 Overview If your rebuilt website lives on a staging subdomain (for example, beta.snazzy.solutions) and is set to noindex, you can still use Search Atlas tools to review, audit, and prepare your site for launch. Because the subdomain is noindex, search engines will not crawl or rank it — but Search Atlas crawls your site directly, so noindex tags do not block its analysis. ⚙️ What You Can and Cannot Do on a Staging Subdomain Understanding these boundaries will help you get the most out of Search Atlas before launch. - What works: Site audits, on-page SEO analysis, content reviews, internal link analysis, and OTTO SEO recommendations all function normally on a staging subdomain. Search Atlas crawls your site independently of Google's index. - What is limited: Rank tracking and keyword position data rely on live search engine results. A noindex staging subdomain will not appear in search rankings, so rank data will not be available until the site is live on your production domain. - Backlink data: A brand-new staging subdomain will have no backlink history. Backlink metrics become meaningful once you launch on your permanent domain. 🚀 Step 1 — Add Your Staging Subdomain as a Project 1. Log in to Search Atlas and go to the left sidebar. 2. Go to Home and click Create Project and enter your full staging subdomain URL, for example https://beta.snazzy.solutions. 3. Complete the setup wizard and save. Search Atlas will begin crawling the subdomain immediately. 📊 Step 2 — Run a Site Audit Once your staging project is saved, run a full site audit to surface technical and on-page issues before launch. 1. Open your staging project from Site Explorer. 2. Navigate to the Site Audit section within the project dashboard. 3. Click Start Audit and wait for the crawl to complete. 4. Review errors, warnings, and notices. Pay particular attention to broken links, missing meta tags, duplicate content, slow page speed, and crawlability issues that you will want fixed before going live. Tip: Even though the staging site is noindex, make sure your robots.txt on the staging subdomain does not block Search Atlas's crawler. If it does, the audit will return incomplete results. 💡 Step 3 — Use OTTO SEO for Pre-Launch Recommendations OTTO SEO can analyse your staging pages and generate actionable recommendations. Apply fixes directly in your CMS or page builder before launch so your production site is optimised from day one. 1. From your staging project, activate OTTO SEO. 2. Review the prioritised list of recommendations covering titles, meta descriptions, heading structure, image alt text, and more. 3. Implement the suggested changes on your staging environment and re-crawl to verify fixes. 🔄 Step 4 — Transition to Your Production Domain at Launch When you are ready to go live, add your production domain as a separate project in Search Atlas. Your staging project can remain for reference, but all ongoing rank tracking, backlink monitoring, and keyword reporting should be set up under the production domain. 1. Add your live domain (for example, https://snazzy.solutions) as a new project via Home → Create Project. 2. Set up Rank Tracker under Left sidebar → Keywords → Rank Tracker for the production domain to begin monitoring keyword positions. 3. Run a fresh site audit on the production domain post-launch to confirm all staging fixes carried over correctly and that noindex tags have been removed from live pages. ❓ Frequently Asked Questions - Will noindex on my staging pages affect my audit results? No. Search Atlas crawls your site directly and does not rely on Google's index to perform audits or on-page analysis. - Can I track keywords against my staging subdomain? Keyword rank tracking requires pages to be indexed by search engines. Use the Rank Tracker only after launching on your production domain. - Do I need to remove the staging project after launch? You do not have to, but we recommend creating a new project for your production domain to keep your data clean and relevant. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🕷️ Fix WordPress Crawl Blocked on SiteGround

🔍 Why Your Site Audit Crawl Gets Stuck If your Site Audit crawl has been running for more than 24 hours without completing — or shows no progress at all — SiteGround's built-in security tools are almost certainly blocking the Search Atlas crawler. This is one of the most common reasons WordPress sites hosted on SiteGround fail to crawl successfully. SiteGround uses two layers of protection that can silently block automated crawlers: - SiteGround Security plugin — flags and bans IP addresses that make rapid, repeated requests (exactly what a crawler does). - Cloudflare integration — SiteGround routes traffic through Cloudflare by default, which can trigger bot-protection rules that block crawl requests before they even reach your server. Because these blocks happen silently, your crawl appears to be running but never actually retrieves any pages. ✅ Before You Start: Confirm the Issue Check these two things first to confirm a block is the cause: 1. Your Site Audit project was added recently and the crawl has not completed after 24+ hours. 2. Your WordPress site is hosted on SiteGround (check your hosting dashboard or domain registrar if unsure). If both are true, follow the steps below in order. 🛠️ Step 1 — Whitelist the Crawler in the SiteGround Security Plugin If you have the SiteGround Security plugin installed on your WordPress site, it may have automatically banned the Search Atlas crawler IP range. Here is how to allow it: 1. Log in to your WordPress admin dashboard. 2. In the left menu, go to Security → Blocked IPs. 3. Look for any recently blocked IP addresses. If you see entries added around the time your crawl started, these are likely the Search Atlas crawler IPs. 4. Select those entries and click Unblock. 5. Next, go to Security → Activity Log Settings and add the Search Atlas crawler user agent (SearchAtlasBot) to your allowlist so it is not blocked in future crawls. If you are unsure which IPs belong to Search Atlas, open the chat widget and a teammate can provide the current IP ranges. ☁️ Step 2 — Adjust Cloudflare Bot Protection SiteGround enables Cloudflare by default for many hosting plans. Cloudflare's bot-fight mode or firewall rules can block the crawler independently of the SiteGround Security plugin. 1. Log in to your SiteGround hosting dashboard. 2. Go to Speed → Cloudflare and click Manage next to your domain. 3. Inside Cloudflare, navigate to Security → Bots. 4. If Bot Fight Mode is enabled, temporarily disable it and restart your crawl to test whether this resolves the issue. 5. Alternatively, go to Security → WAF → Firewall Rules and create an allow rule for the SearchAtlasBot user agent so Cloudflare does not challenge or block it. Note: You can re-enable Bot Fight Mode after whitelisting the Search Atlas user agent. Disabling it permanently is not necessary or recommended. 🔄 Step 3 — Restart Your Site Audit Crawl After completing the steps above, restart the crawl from Search Atlas: 1. In the left sidebar, go to OTTO SEO → Site Audit → Overview (Website Overview). 2. Find your affected project. 3. Click Recrawl Site (or delete and re-add the project if the crawl appears frozen). 4. Monitor progress over the next 15–30 minutes. Most sites complete an initial crawl within this window once the block is lifted. 💡 Tips to Prevent This in the Future - Whitelist SearchAtlasBot before adding new projects — if you host multiple sites on SiteGround, whitelist the crawler user agent proactively in both the SiteGround Security plugin and Cloudflare. - Check your SiteGround Activity Log regularly — the plugin logs blocked IPs in real time, making it easy to spot false positives. - Avoid aggressive rate-limiting rules — if you have custom Cloudflare firewall rules that throttle requests per IP, consider excluding known SEO tool bots from those rules. 💬 Still Seeing Issues? If your crawl is still stuck after following all the steps above, there may be a server-level firewall rule or a custom .htaccess restriction that requires closer inspection. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🚀 Deploy All Site Audit Suggestions Correctly

🔍 Overview The Deploy All button in the OTTO SEO V3 tool lets you apply AI-generated SEO suggestions — such as title tags, meta descriptions, and other on-page fixes — to your site in bulk. However, there is an important workflow step that must be completed first: AI suggestions must finish generating before Deploy All will apply them all. If you click Deploy All too early, only the suggestions that have already been generated at that moment will be deployed. This is the most common reason customers see partial deployments, such as 10 out of 55 title tags being applied. ⚙️ How the Deploy All Workflow Works 1. Go to Left sidebar → OTTO SEO → SEO Automation (URL: /seo-automation-v3). 2. Add your domain and complete the initial site setup if you have not already done so. 3. Once the site is connected, OTTO SEO V3 will begin crawling your site and generating suggestions for each page. This process runs in the background and can take several minutes depending on the size of your site. 4. Wait for suggestion generation to complete. You will see a progress indicator showing how many suggestions have been created. Do not click Deploy All until this process is finished. 5. When all suggestions are ready, click Deploy All to apply every generated suggestion to your site at once. ⚠️ Why Only Some Suggestions Deployed If you clicked Deploy All before suggestion generation was complete, the system deployed only the suggestions that existed at that moment. The remaining suggestions were still being generated in the background and were not yet available to deploy. This is the most common cause of partial deployments. It is not a bug — it is a timing issue in the workflow. 🛠️ How to Fix a Partial Deployment If you have already deployed a partial set of suggestions, follow these steps to deploy the rest: 1. Go to Left sidebar → OTTO SEO → SEO Automation. 2. Select your domain from the dashboard. 3. Wait until the suggestion generation progress indicator shows that all suggestions are complete. 4. Review the remaining undeployed suggestions to confirm they look correct. 5. Click Deploy All again — this will apply only the suggestions that have not yet been deployed, so previously deployed items will not be duplicated or overwritten. 💡 Best Practices for Deploying Suggestions - Always wait for full generation before deploying. Check that the progress indicator shows 100% or a completed status before clicking Deploy All. - Review suggestions before deploying. You can browse individual suggestions by page or by suggestion type — such as title tags or meta descriptions — to confirm the AI recommendations meet your expectations. - Deploy in stages if preferred. Instead of using Deploy All, you can select specific suggestion categories or individual pages and deploy them separately for greater control. - Check your deployment log. After deploying, review the log inside OTTO SEO V3 to confirm how many suggestions were successfully applied and identify any that may need manual attention. ❓ Frequently Asked Questions How long does suggestion generation take? Generation time depends on the number of pages on your site. Small sites may complete in a few minutes; larger sites can take longer. You will see a live progress indicator inside the OTTO SEO V3 dashboard. Will clicking Deploy All a second time overwrite what was already deployed? No. Deploy All only applies suggestions that have not yet been deployed. Already-deployed suggestions are not affected. Can I deploy suggestions for just one type, like title tags only? Yes. Inside OTTO SEO V3, you can filter suggestions by type and deploy a specific category rather than all suggestions at once. 🆘 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 Score Drops and OTTO Authority Building

Why Your Site Audit Score May Still Drop After Fixing Issues Fixing suggested tasks is a great first step, but a dropping or stagnant Site Audit score is usually caused by one of the following reasons: - New issues were detected in a later crawl. Each time your site is recrawled, OTTO may discover new technical problems that offset the fixes you applied. The score reflects the full picture of your site's health at the time of each crawl, not just the tasks you resolved. - Fixes have not yet been crawled. The Site Audit score updates only after a fresh crawl is completed. If you fixed issues but a new crawl has not run, your score will not reflect those changes yet. - Underlying issues remain in related areas. Resolving one category of tasks (for example, broken links) does not raise your score if other weighted categories (for example, Core Web Vitals or missing meta tags) still have open issues. - Score weighting. Not all tasks carry equal weight. A small number of high-priority issues can lower your score significantly even when many lower-priority tasks are resolved. To update your score, trigger a fresh crawl from OTTO SEO → Site Audit → Overview (Website Overview) and click the Recrawl Site button once your fixes have been applied. How OTTO Optimizations Interact With Site Audit Scoring OTTO applies on-page and technical optimizations directly to your site. However, Site Audit scoring and OTTO optimizations operate on separate cycles: - OTTO deploys fixes when you approve or auto-apply tasks inside your project. - The Site Audit score only updates after the next scheduled or manually triggered crawl. - There may be a delay between a fix being deployed and the crawl capturing it. This means a score of 0 or a very low score immediately after applying OTTO tasks does not necessarily indicate the fixes failed — it may simply mean the crawl that reflects those changes has not completed yet. Allow at least one full crawl cycle before evaluating the impact of your optimizations. What Is OTTO Authority Building and Why Does It Show 0? OTTO Authority Building is a separate set of off-page SEO tools designed to increase your domain authority. A score of 0 in Authority Building means no Authority Building campaigns or assets have been created yet for your project. It is not an error — it is a starting point. Authority Building does not affect your on-page Site Audit score directly. It improves your domain's overall authority over time, which supports higher rankings and long-term score improvements across your project. How to Get Started With Authority Building To begin using Authority Building features, navigate to the left sidebar → Authority (Press Releases) within Search Atlas and start creating campaigns or assets for your project. If you are unsure which Authority Building features are available on your plan, review your account's feature access within the platform 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.

🗂️ Free Up Site Auditor Project Slots Fast

🔍 Understanding the Site Auditor and OTTO Project Link Every Site Auditor project in Search Atlas is connected to an OTTO project. When you activate OTTO for a website, a Site Auditor project is automatically created alongside it. This means your Site Auditor Projects quota and your OTTO Sites quota share the same underlying slots — they are not independent limits. If your plan allows 5 Site Auditor Projects, you can have a maximum of 5 active or frozen OTTO-linked projects at any one time. Once you reach that cap, you cannot add a new site until you free at least one slot. ❄️ Why You Cannot Delete a Frozen Project A frozen OTTO project is one that has been paused but not fully removed. Search Atlas prevents you from deleting a Site Auditor project while it is still linked to an active or frozen OTTO client. This is a safeguard to protect your OTTO configuration and historical audit data from accidental loss. To delete the Site Auditor project and reclaim the slot, you must first unfreeze the linked OTTO project, and then delete it. Attempting to delete the Site Auditor project directly while the OTTO link exists will always fail. ✅ How to Free a Site Auditor Slot Step by Step 1. Go to OTTO SEO → All Sites (SEO Automation) using the left sidebar (or navigate to /seo-automation-v3). 2. Find the frozen OTTO project you want to remove. Frozen projects are visually marked and listed alongside your active projects. 3. Open the project and select Unfreeze to restore it to an active state. You do not need to re-run any tasks — this simply removes the frozen status so the project becomes editable. 4. Once the project is active again, select Delete (or the equivalent remove option shown in the project menu) to permanently remove the OTTO project. 5. Confirm the deletion when prompted. Search Atlas will automatically remove the linked Site Auditor project at the same time, releasing one slot from your quota. 6. Return to OTTO SEO → All Sites (SEO Automation) and confirm your Site Auditor Projects count has decreased before adding your new site. Repeat these steps for each frozen project you want to remove until you have enough free slots for your new OTTO site. 📊 How to Check Your Current Quota You can view how many Site Auditor slots you have used and how many remain at any time: - Click Home in the left sidebar (or go to /home). - Select Quotas from the available actions on the Home page. - Look for Site Auditor Projects in the quota list to see your current usage against your plan limit. If your quota shows the correct number after deleting a frozen project but you still cannot add a new site, try refreshing the page before attempting to create the new OTTO project. ⚠️ Important Things to Know Before Deleting - Deletion is permanent. Once you delete an OTTO project and its linked Site Auditor project, all associated audit history, crawl data, and OTTO recommendations for that site are removed and cannot be recovered. - Unfreezing is temporary. Unfreezing a project only changes its status so you can delete it — it does not restart any OTTO tasks or consume additional credits. - Plan upgrades are an alternative. If you need to keep all your existing projects and still add new sites, consider upgrading your plan to increase your Site Auditor Projects limit. You can review available plans from the platform. 💬 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 Cloud Stacks That Won't Index

🔍 Overview Cloud stacks are designed to support your link-building and authority strategy, but Google does not guarantee indexation for any URL — including cloud stack pages. If your cloud stack URLs have not been indexed after several months, this article explains why that happens and what you can do about it, including how to use the built-in Indexing Tool to manually submit URLs to Google. ⚠️ Why Cloud Stack URLs May Not Get Indexed Google crawls and indexes URLs at its own discretion. Even well-structured cloud stack pages can go unindexed for a variety of reasons: - Low crawl priority: New or low-authority domains are crawled less frequently by Googlebot. - Lack of inbound links: Pages with no external links pointing to them are harder for Google to discover. - Crawl budget constraints: On large sites or networks, Google may not allocate crawl budget to every page. - Content thinness: Pages that appear low-value or duplicative may be deprioritised or skipped entirely. These factors can delay indexation by weeks or even months, regardless of how the cloud stack was built. ✅ What You Can Do: The Indexing Tool If your cloud stack URLs have not been indexed after a reasonable amount of time, the most direct solution is to use the Indexing Tool inside Search Atlas. This tool lets you manually submit URLs to Google for indexation rather than waiting for organic discovery. To access the Indexing Tool, go to Left sidebar → Authority → Indexer (URL Indexer). 📋 How to Submit URLs with the Indexing Tool 1. Navigate to Left sidebar → Authority → Indexer (URL Indexer). 2. Click Index URLs on the page. 3. Paste the cloud stack URLs you want to index, one per line. 4. Review the list to confirm all URLs are correct. 5. Click Index URLs to send the URLs for indexation. 6. Monitor the status column over the following days to track whether each URL has been picked up by Google. Each URL push costs approximately $0.10 per URL. This cost is deducted from your account credits. Make sure your account has sufficient credits before submitting a batch of URLs. 💡 Tips for Better Indexation Results - Prioritise your most important URLs first. Submit cloud stack pages that are closely tied to your target keywords or anchor text strategy. - Combine the Indexing Tool with linking. URLs that also receive inbound links — from blog posts, social profiles, or other authority assets — tend to get indexed faster and stay indexed longer. - Avoid re-submitting too quickly. If a URL has been pushed recently, wait at least 7–10 days before pushing it again to avoid wasting credits. - Check for technical issues first. Before submitting, verify that the cloud stack URL loads correctly and is not returning an error code such as 404 or 503. 🔎 How to Check Whether a URL Is Already Indexed Before spending credits, confirm a URL is genuinely not indexed. The quickest way is to paste the full URL into Google search using the format site:yoururl.com/page. If no result appears, the page is not currently indexed and is a candidate for the Indexing Tool. You can also review indexation status directly within the URL Indexer dashboard, which displays the last known status for each submitted URL. 📍 Where to Find Your Cloud Stack URLs If you are unsure which URLs to submit, navigate to Left sidebar → Authority → Cloud Stacks to view all cloud stacks associated with your account. From there you can copy the individual page URLs and paste them into the URL Indexer. 🕐 What to Expect After Submitting Submitting a URL via the Indexing Tool signals Google to crawl and consider that page for indexation. Most URLs submitted this way are crawled within a few days, though actual indexation is still at Google's discretion. You should see meaningful progress within 7–14 days of submission. If a URL remains unindexed after 14 days despite being pushed, it may indicate a content or technical issue with the page itself that is preventing Google from indexing it. 🆘 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.

🔗 Review OTTO Link Fixes in Site Audit

🔍 What Does 'Issues with Links' Mean in Site Audit? The Issues with Links category in Site Audit flags problems that affect how search engines and visitors navigate your site. OTTO groups these into several issue types, including: - Broken internal links — links pointing to pages that return a 404 or other error - Broken external links — outbound links leading to unavailable destinations - Redirect chains — links passing through multiple redirects before reaching a final URL - Links to redirected pages — internal links targeting a URL that itself redirects elsewhere - Nofollow links to important pages — links blocking PageRank flow to pages that should be crawlable - Missing anchor text — links without descriptive text that help search engines understand context Each issue type is assigned a severity level — Critical, Warning, or Opportunity — so you can prioritise fixes by impact. ⚙️ What Changes Will OTTO Make Automatically? When you deploy OTTO fixes for link issues, OTTO can automatically action the following on supported site types: - Update internal links pointing to redirected URLs so they link directly to the final destination - Remove or replace broken internal links with corrected URLs where a clear replacement exists - Add or improve anchor text on links flagged as missing descriptive text - Adjust nofollow attributes on internal links to allow proper crawling of important pages OTTO will not automatically modify external links pointing to third-party domains, as those changes require direct access to external resources outside your site. Those issues are flagged for your manual review. Before any fix goes live, OTTO presents each proposed change for your approval — nothing is applied to your site without your explicit action during the deployment step. 📋 How to Review Proposed Fixes Before Deployment Follow these steps to inspect what OTTO plans to change before you approve deployment: 1. In the left sidebar, click OTTO SEO, then open SEO Automation inside it to open the OTTO dashboard. 2. Select the relevant site and navigate to the Site Audit section within the OTTO workspace. 3. Click the Issues with Links category to expand the list of detected issues. 4. Click any individual issue type to see a full list of affected URLs and the specific fix OTTO has generated for each one. 5. Review the Current Value and Proposed Fix columns side by side for each item. 6. Use the checkboxes to select the fixes you want to approve, or deselect any you prefer to handle manually. 7. When satisfied, navigate to Local → My Tasks (My Tasks) and click the Deploy all changes button to push your approved changes live. You are always in control — unapproved fixes remain staged and will not affect your site until you explicitly deploy them. 🕓 How to Review Changes After Deployment Once fixes have been deployed, you can audit exactly what OTTO changed and when directly inside the OTTO dashboard: 1. In the left sidebar, click OTTO SEO, then open SEO Automation inside it. 2. Open your site's OTTO workspace and navigate to the Site Audit section. 3. Click the Activity Log tab at the top of the page. This is the correct location to view a timestamped record of all changes OTTO has applied. 4. Use the Category filter and select Links to narrow the log to link-related fixes only. 5. Each entry shows the affected URL, the type of fix applied, the before and after values, and the date and time of deployment. 6. If you need to revert a specific change, select the entry and click Undo Fix to restore the original state. Note: If you previously followed guidance referring to a Fix History page and could not locate it, that section no longer exists in the current platform. The Activity Log tab inside the OTTO Site Audit workspace is the correct and up-to-date location for all deployment history. ✅ Best Practices for Managing Link Fixes - Run a fresh Site Audit crawl after deployment to confirm issues are resolved and no new ones have been introduced. - Review broken external links manually — OTTO flags them but cannot auto-fix links pointing to third-party domains. - Check the Activity Log after each deployment session to maintain a clear record of what has changed on your site. - Use the Undo Fix option promptly if a deployed change produces unexpected results on your site. 💬 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.

⚙️ SEO Audit API Constraints and Supported Workflows

🎯 What This Article Covers Some customers want to trigger a Search Atlas site audit automatically when an external form is submitted — for example, using a GoHighLevel form connected to a Make scenario that calls the Search Atlas API. This article clarifies what is and is not supported so you can design your automation correctly from the start. 🚫 Unsupported Workflow: End-User-Triggered Audits via External Forms Triggering a site audit on behalf of an end user through an external form submission is not a supported workflow. Specifically, the following scenario is not available: - A prospect or client fills out a form (for example, in GoHighLevel). - The form submission triggers a Make scenario. - The Make scenario calls the Search Atlas API to initiate a site audit for that user's domain. - The completed report is retrieved and sent to a third-party AI tool (such as Claude) for editing. - The edited report is emailed to the end user automatically. Even though this flow may appear technically plausible based on API documentation, it is outside the intended use of the audit system and will not function as expected. Attempting to build this workflow will result in errors, incomplete data, or unsupported behavior that our support team cannot troubleshoot. ✅ Supported Workflow: Account Owner Initiates Audits from the Dashboard Site audits in Search Atlas must be initiated by the account owner from inside the platform. This is the only supported method for starting a new audit. Log in to your Search Atlas account and navigate to the site audit area of the dashboard to configure and run an audit for a project under your account. This ensures audits are run with the correct account permissions, accurate project configuration, and full access to all reporting features. ⚙️ What the API Does and Does Not Support The Search Atlas API is designed to support account owners and their internal tools — not end-user-facing automation flows. Here is a general breakdown based on the intended design of the system: - Supported: Retrieving audit data for projects already created and run under your own account. - Supported: Reading report results programmatically to feed into your own dashboards or internal tools. - Supported: Managing projects and accessing data on behalf of your own account. - Not supported: Initiating new audits on arbitrary domains submitted by third-party users via external forms or automation triggers. - Not supported: Acting as a middleman API layer that processes external user requests and triggers audits dynamically on demand. If you are building an automation and need to confirm which specific API endpoints are available for reading audit data or managing projects, refer to the Search Atlas API documentation available within your account, or contact our team for guidance on what is achievable within the supported scope. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🗺️ Disable URL Types in Search Atlas Sitemaps After Yoast Migration

🔍 Overview When you migrate from Yoast to Search Atlas, your previous sitemap exclusion settings are not automatically carried over. If you had author pages, video pages, category pages, or tag pages disabled in Yoast, you will need to re-apply those exclusions directly in Search Atlas. This article explains what to do and what to have ready when contacting support. ⚠️ Why This Matters Pages that return errors — such as 404s or thin-content pages — should not appear in your sitemap. Including them can signal quality issues to search engines and negatively affect your site's crawl budget. Disabling these URL types in your Search Atlas sitemap keeps it clean and aligned with your SEO strategy. 🧭 How to Access Your Sitemap Settings 1. Log in to your Search Atlas account. 2. Navigate to the project associated with the domain you migrated from Yoast. 3. Look for a sitemap or sitemap configuration area within your project settings. The exact location may vary depending on your account setup — if you cannot locate it, see the escalation steps below. 🚫 Disabling Specific URL Types Within your sitemap settings, you should be able to control which URL types are included in your sitemap. Common URL types that users disable after a Yoast migration include: - Author pages — archive pages grouped by post author - Video pages — pages associated with video content - Category pages — taxonomy archive pages for post categories - Tag pages — taxonomy archive pages for post tags If your sitemap settings include controls for these URL types, disable the ones you want to exclude and save your changes. After saving, regenerate or refresh your sitemap so the exclusions take effect. If you do not see controls for specific URL types in your sitemap settings, this configuration may need to be applied by the Search Atlas support team on your behalf. Please see the escalation steps below. ✅ Verifying Your Changes After saving and refreshing, confirm the excluded URL types no longer appear in your sitemap: - Open your live sitemap URL (typically yourdomain.com/sitemap.xml) and check that author, video, category, or tag URLs are absent. - If your sitemap is split into sub-sitemaps (e.g., a dedicated category sitemap), verify those sub-sitemaps are also removed or empty. 📋 Before You Escalate — What to Have Ready If you cannot locate the URL type controls in your sitemap settings, or if the exclusions are not taking effect after saving, please reach out to the support team with the following information: - Your project name and the domain you migrated from Yoast - The specific URL types you need to disable (e.g., author, video, category, tag) - A description of what you see in your current sitemap settings, or a note that you cannot locate the sitemap configuration area - Any error messages or unexpected behavior you have observed If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix Specific Site Audit SEO Issues by Page

🗺️ How to Navigate to a Specific Issue Every flagged item in the Site Audit links directly to the affected page and issue type. To reach the fix view, open the Site Audit report, click the issue count next to any category, then click an individual URL to see all issues flagged for that page. Use the sections below to act on each issue type once you land there. 🧩 Schema Markup Issues Schema errors tell search engines your structured data is incomplete or invalid, which can prevent rich results from appearing. 1. Missing schema: Identify the page type (article, product, FAQ, local business). Add the matching JSON-LD block inside a <script type="application/ld+json"> tag in the <head>. Use schema.org for the required properties for each type. 2. Invalid or incomplete schema: Copy your existing JSON-LD into Google's Rich Results Test. Fix every property marked as missing or incorrect, then re-validate before republishing. 3. Duplicate schema blocks: Remove all but one JSON-LD block of the same type per page. Duplicates cause parsing conflicts and can suppress rich results. 🖼️ Image Optimization Issues Unoptimized images slow page load and miss accessibility signals that search engines use for ranking. 1. Missing alt text: Add a descriptive alt attribute to every <img> tag. Example — Before:<img src="shoe.jpg"> | After:<img src="shoe.jpg" alt="Red running shoe with white sole">. Keep alt text under 125 characters and avoid keyword stuffing. 2. Oversized file size: Compress images to under 150 KB where possible. Use WebP format instead of PNG or JPEG. Tools like Squoosh or ShortPixel can batch-compress your library without visible quality loss. 3. Missing width and height attributes: Add explicit width and height values to every <img> tag to prevent Cumulative Layout Shift (CLS), which directly impacts Core Web Vitals scores. 📝 Page Title Issues Page titles are one of the highest-impact on-page SEO elements. Search Atlas flags titles that are too short, too long, missing, or duplicated. 1. Title too long (over 60 characters): Trim the title so the primary keyword appears within the first 60 characters. Everything beyond roughly 580 px of rendered width is truncated in search results. 2. Title too short (under 30 characters): Expand the title to include your primary keyword and a secondary modifier or brand name. A strong structure is: Primary Keyword – Secondary Modifier | Brand. 3. Missing title tag: Add a <title> tag inside the <head> of the page. Every page must have exactly one unique title tag. 4. Duplicate titles: Open Content → Meta Generator in the left sidebar to generate unique, keyword-targeted titles for each affected URL at scale. 🔗 Link Issues Link issues split into two categories: broken links that return errors and internal linking gaps that limit crawl depth and authority flow. 1. Broken internal or external links (4xx/5xx): Click the flagged URL in the Site Audit to see the exact broken link and the page it lives on. Fix internal broken links by updating the href to the correct destination URL, or redirect the broken target with a 301. For broken external links, replace them with a working equivalent or remove them entirely. 2. Orphaned pages (no internal links pointing to them): Navigate to Content → On-Page Audit in the left sidebar, enter the orphaned page's URL, and use the internal linking suggestions to find contextually relevant pages on your site that should link to it. Add those links in your CMS. 3. Low internal link count: Use the Page Explorer integration inside the Site Audit to identify high-authority pages on your domain. Add contextual anchor-text links from those pages to the under-linked URL, prioritising anchors that include the target page's primary keyword. ⚡ Technical Performance Issues Technical issues affect page speed and crawlability. The two most common flags are render-blocking resources and uncompressed assets. 1. CSS and JavaScript not minified: Enable minification in your CMS or build tool. In WordPress, plugins such as WP Rocket or NitroPack handle this automatically. In custom builds, add a minification step to your deployment pipeline (e.g., using Terser for JS and CSSNano for CSS). After enabling, re-run the Site Audit to confirm the flag clears. 2. Compression not enabled (Gzip/Brotli): Enable Gzip or Brotli compression at the server or CDN level. For Apache, add mod_deflate rules to your .htaccess. For Nginx, set gzip on; in your config. Most CDNs (Cloudflare, Fastly) offer a one-click compression toggle in their dashboard. 3. Render-blocking resources: Move non-critical CSS to load asynchronously and add defer or async attributes to non-essential JavaScript tags so they do not block the initial page render. 🎨 Inline Style Issues Inline styles (style attributes written directly on HTML elements) bloat page HTML, make maintenance harder, and can conflict with your site's CSS cascade. 1. Search your page's source for style=" to locate all inline declarations. 2. Move each style rule into your external stylesheet, assigning a class or ID to the element instead. 3. Before:<p style="color: red; font-size: 14px;"> | After:<p class="note-text"> with .note-text { color: red; font-size: 14px; } in your CSS file. 4. If your CMS page builder injects inline styles automatically, switch to a CSS custom properties or theme settings approach within the builder to keep styling out of the HTML markup. ✅ Verifying Your Fixes After making changes, return to the Site Audit and click Recrawl on the affected project. Once the crawl completes, open the same issue category and confirm the flagged URLs no longer appear. For titles and meta descriptions, you can also use Content → Meta Generator to audit and update metadata in bulk before re-crawling. 💬 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 Audit Healthy Pages Showing Zero Score

🧐 What Does a Zero Healthy Pages Score Mean? If your Site Audit shows 0 healthy pages, it does not necessarily mean your site has no healthy content. In most cases, this reading appears because the audit has not yet completed its full crawl, the results have not been refreshed after a recent crawl, or all crawled pages currently have at least one flagged issue preventing them from being classified as healthy. A page is only counted as healthy when it passes every technical check in the audit. Even a single minor issue — such as a missing meta description or a slow load time — moves that page out of the healthy category. ⚙️ How to Diagnose the Zero Score 1. Check the crawl status. Navigate to your Site Audit dashboard and confirm the crawl shows a Completed status. If the crawl is still running or was interrupted, wait for it to finish and then refresh the page. 2. Review the total pages crawled. If the crawled page count also shows zero, the crawler may not have been able to access your site. Verify that your robots.txt file is not blocking the Search Atlas crawler and that your site is publicly accessible. 3. Look at issue distribution. Open the Issues tab within Site Audit. If every page carries at least one flagged issue, that explains the zero healthy count. Focus on resolving the most common issues first to move pages into the healthy column. 4. Re-run the crawl. If you recently made fixes to your site, the current results will not reflect those changes. Trigger a new crawl by going to OTTO SEO → Site Audit → Overview (Website Overview) and clicking Recrawl Site and allow it to complete before reviewing your scores again. 📋 Understanding the Pruning Report The Pruning Report is the Page Pruning page inside Site Audit (OTTO SEO → Site Audit → Page Pruning for the selected audit) and is designed to help you identify pages that may be diluting your overall site quality. It groups pages into categories based on their performance signals, such as low traffic, thin content, or poor engagement metrics. Here is how to use the pruning report effectively: - Review each category separately. Pages are grouped by the type of concern — for example, low organic traffic, duplicate content, or no inbound internal links. Work through one category at a time rather than trying to address everything at once. - Decide on an action for each page. For every page flagged, you have three main options: Improve the page by adding value, Consolidate it by merging it with a related page, or Remove it if it provides no value and cannot be improved. - Use the status column. Mark each page with your chosen action inside the report. This helps you track progress and keeps your audit organised over time. - Do not delete pages impulsively. Always check whether a flagged page has any inbound links, conversions, or direct traffic before deciding to remove it. The report highlights candidates for pruning — the final decision is yours. ✅ How to Improve Your Healthy Pages Count Raising the number of healthy pages is a gradual process. Follow these steps to make consistent progress: 1. Open the Issues tab in Site Audit and sort issues by pages affected to find the highest-impact problems. 2. Address widespread technical issues first — such as missing title tags, broken internal links, or pages returning error status codes — because fixing one issue type can unlock healthy status for many pages at once. 3. After making changes on your site, return to Site Audit and run a new crawl to update your results. 4. Repeat this cycle regularly. Aim to schedule crawls at least once a week so your healthy pages metric stays current. 💡 Tips for Keeping Your Score Accurate - Make sure the correct domain is connected and verified in your project settings before running a crawl. - If your site uses JavaScript-heavy rendering, some pages may not be fully crawled. Check your crawl settings and ensure the crawler is configured to handle your site's technology. - Keep your crawl frequency consistent. Infrequent crawls mean the data you see may not reflect recent improvements or regressions. 🛠️ Still Seeing Zero After a Full Crawl? If your healthy pages count remains at zero after completing a fresh crawl and you have confirmed there are no blocking issues on your site, our team can investigate the crawl 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.

🔄 Technical Help After a Major Brand Change

🧭 Overview A major rebrand — such as a new business name, domain, logo, address, or phone number — can affect multiple areas inside Search Atlas. This article walks you through the key places to update your brand information and explains what to do if you run into issues along the way. ✅ Step 1: Update Your Brand Vault Brand Vault is the central hub that stores your business identity across Search Atlas. After a rebrand, this is the first place to update. 1. Navigate to Brand Vault: top-right More Features menu (grid icon, next to your Avatar Menu (👤)) → Brand Vault, or OTTO SEO in the left sidebar → All Sites (SEO Automation) → open your project → Brand Vault. 2. Update your business name, address, phone number, website URL, and any other changed details. 3. Review all fields carefully — even small mismatches (like an old suite number) can cause inconsistencies in citations and local SEO tools. 4. Save your changes before leaving the page. Important: If your business has multiple locations, each location must be updated individually. There is currently no bulk-edit option for multi-location Brand Vault entries, so work through each location one at a time. 🔍 Step 2: Reconnect or Review Google Business Profile (GBP) If your rebrand includes a new business name or address, your Google Business Profile connection may need attention. - Go to Local (GBP Projects) in the left sidebar and confirm your profile is still connected correctly. - If your GBP listing has been updated in Google, allow up to 24 hours for changes to reflect inside the platform. - For multi-location businesses, verify that each location's GBP is linked to the correct Brand Vault entry. 🤖 Step 3: Review OTTO SEO Settings OTTO SEO uses your brand data to power automations and keyword recommendations. After a rebrand, some settings may need to be refreshed. 1. Go to OTTO SEO → SEO Automation in the left sidebar (URL: /seo-automation-v3). 2. Check that OTTO is referencing your updated brand name and domain. 3. If you manually modified any keywords before the rebrand, review them — a Google Search Console sync can sometimes reset user-modified keywords and toggle states. Re-apply any custom changes as needed. 4. Re-run any OTTO automations that were tied to your old brand identity to ensure they reflect your new branding. 🌐 Step 4: Check Your Domain and Site Explorer Data If your rebrand includes a new domain name, Site Explorer data for the old domain will not automatically carry over. - Add your new domain as a project inside Search Atlas. - Historical data from your old domain will remain accessible under the old project but will not merge with the new one. - Allow 24–48 hours for fresh data to populate for a newly added domain. - If any metrics sections appear empty or fail to load after adding the new domain, wait and refresh — data population can take time for new domains. 📋 Step 5: Rerun Your Citation Scan Citations across the web may still reference your old brand name, address, or phone number. Running a new Citation Scan after updating Brand Vault will surface outdated listings that need correction. 1. Open the Citation Scan tool inside Search Atlas. 2. Confirm your Brand Vault details are saved correctly before starting the scan. 3. Review the results and prioritise fixing listings on high-authority directories. ⚠️ Common Issues After a Rebrand - Brand Vault fields not saving: Refresh the page and re-enter the information. If the issue persists, clear your browser cache and try again. - GBP data not updating: Ensure your GBP listing is fully verified and published in Google before expecting it to sync inside Search Atlas. - OTTO keywords reverting: After a GSC sync, manually re-apply any custom keyword changes inside OTTO SEO. - Site Explorer showing no data: New domains need time to index. Check back after 48 hours. 💬 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.

🔍 Understanding Site Audit Limitations and Issue Reporting

Overview The Search Atlas Site Audit scans your website and surfaces technical SEO issues that may be hurting your rankings. This article explains how audit results are counted and displayed, which types of issues require a web developer to fix, and what Search Atlas can — and cannot — do on your behalf. How Issue Counts Are Calculated Search Atlas counts issues at the page-instance level, meaning the same issue type is counted once for every page where it appears. For example, if 50 pages are missing a meta description, the audit reports 50 instances — not one issue. This approach gives you a precise picture of how widespread each problem is across your site. You may notice that your issue count looks higher compared to other SEO tools. This is intentional: tools that deduplicate by issue type can mask the true scale of a problem. Search Atlas prioritises accuracy so you can make informed prioritisation decisions. Viewing Issues at the Page Level When reviewing audit results, you can identify which specific pages are affected by each issue type. Here is how to get the most out of the reporting: 1. Open your project and navigate to the Site Audit report. 2. Select any issue category to see its detail view. 3. The issue detail view lists the affected URLs so you know exactly which pages need attention. 4. Use this page-level data to prioritise fixes — start with high-traffic or high-priority pages first. If a page fails to crawl during the audit, it may not appear in the results. This does not mean the page is issue-free; it means the crawler could not access it. Common causes include server-side restrictions, login-protected pages, or pages that were otherwise inaccessible to the crawler. Check those pages manually if you suspect they were skipped. What Search Atlas Can Fix Automatically Search Atlas is an SEO intelligence and automation platform. Through OTTO SEO, the platform can automatically apply certain on-page optimisations, including meta title and description updates and heading tag optimisations, when OTTO has the necessary site access and the relevant automation is active. Refer to the OTTO SEO section of the platform for details on which automations are available and how to enable them. Issues That Require a Web Developer Many technical SEO issues flagged in the audit sit at the infrastructure or code level and cannot be resolved by an SEO platform alone. Issues in this category typically include: - Site speed and Core Web Vitals — server response times, render-blocking resources, image optimisation at scale - Crawlability and indexability problems — misconfigured robots.txt files, redirect chains, or canonicalisation errors that require direct server or CMS access - Structural or template-level changes — fixes that must be applied across your site's codebase or CMS templates If you are unsure whether an issue requires developer involvement, review the issue description in the audit report for guidance, or consult with your web developer before making 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 Twitter Card Metadata and Choose Your CMS

🔍 Overview Two questions come up frequently together: how to fix broken Twitter Card metadata, and which CMS platform—Shopify or WordPress—is the better home for your articles when using Search Atlas. This guide answers both clearly so you can take action right away. 🐦 What Is Twitter Card Metadata and Why Does It Break? Twitter Cards control how your content appears when shared on Twitter (now X). When the metadata is missing or misconfigured, your shared links show as plain text instead of rich previews with images, titles, and descriptions. This hurts click-through rates and brand credibility. The most common causes of broken Twitter Card metadata are: - Missing twitter:card tag — This is the required base tag. Without it, no Twitter Card will render. - Missing or incorrect twitter:title and twitter:description tags — Twitter falls back to Open Graph tags if these are absent, but explicit tags are always more reliable. - Missing twitter:image tag — No image tag means no visual preview. The image must be publicly accessible and at least 120×120 px (recommended: 1200×628 px for summary_large_image cards). - Wrong card type declared — Using summary when you intend summary_large_image results in a small, unimpressive preview. - Robots meta tag blocking crawlers — If your page has noindex or blocks Twitterbot in robots.txt, the card will not load. - Cached old metadata — Twitter caches card data aggressively. Even after a fix, old data may persist until the cache expires or you force a refresh. 🛠️ How to Fix Twitter Card Metadata 1. Audit your existing tags. Use the Twitter Card Validator (or any meta tag inspector) to see exactly which tags are present or missing on your page. 2. Add the required tags to your page's <head> section. At minimum you need: twitter:card, twitter:title, twitter:description, and twitter:image. 3. Choose the right card type. Use summary_large_image for blog posts and articles—it produces the largest, most engaging preview. 4. Verify your image is accessible. Paste the image URL directly into a browser tab. If it does not load, Twitter cannot fetch it either. 5. Check your robots settings. Confirm Twitterbot is not blocked in robots.txt and that the page is indexable. 6. Clear Twitter's cache. Re-enter your URL in the Twitter Card Validator and click Preview Card. This forces Twitter to re-crawl the page and update its cache. 7. Re-test after 15–30 minutes. Allow time for propagation, then share the URL in a tweet draft to confirm the rich preview appears correctly. 📊 Shopify vs. WordPress — Which Should You Use for Publishing Articles? If your goal is content marketing and SEO, the platform you choose has a meaningful impact on how much control you have over your metadata, technical SEO, and publishing workflow. Shopify is an excellent e-commerce platform, but its blogging capabilities are limited. Key constraints include: - Restricted access to the <head> section without theme code edits, making metadata customisation harder. - Limited SEO plugin options compared to WordPress. - Less granular control over URL structures, schema markup, and advanced on-page SEO settings. - Twitter Card and Open Graph tags often require theme-level modifications that can break during theme updates. WordPress is built for content publishing and offers significantly more flexibility for SEO: - Full control over <head> metadata via plugins like Yoast SEO or Rank Math, making Twitter Card fixes straightforward. - Extensive plugin ecosystem for schema, redirects, sitemaps, and more. - Clean, customisable URL structures that support SEO best practices. - Easier integration with third-party SEO tools. 🔄 Search Atlas CMS SYNC — The Deciding Factor Search Atlas offers CMS SYNC directly with WordPress. This means you can research, optimise, and publish content from inside the Search Atlas platform straight to your WordPress site — no copy-pasting, no formatting loss, no workflow friction. CMS SYNC lets you: - Push fully optimised articles from Search Atlas to WordPress in one click. - Maintain consistent metadata, headings, and on-page SEO elements automatically. - Save significant time by managing your entire content workflow from a single dashboard. Because CMS SYNC is built for WordPress and not Shopify, WordPress is the strongly recommended platform for publishing SEO articles when you are using Search Atlas. Shopify remains a great choice for your storefront, but your blog and content hub will perform better—and integrate more smoothly—when hosted on WordPress. ✅ Quick-Reference Checklist - Twitter Card fix: Add twitter:card, twitter:title, twitter:description, twitter:image to every article page. - Card type: Use summary_large_image for articles. - Image size: 1200×628 px, publicly accessible URL. - Cache reset: Use the Twitter Card Validator after every fix. - CMS choice: Use WordPress for content publishing to take full advantage of Search Atlas CMS SYNC. 💬 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.

🚀 Crawl a Vercel Staging Site Without Google Indexing

🔍 Overview Search Atlas needs to access your website in order to crawl pages, run audits, and power OTTO SEO. If your staging environment is protected by a Vercel deployment passcode, Search Atlas cannot crawl it — the passcode blocks all automated crawlers, including ours. This article explains how to set up a crawlable staging environment that stays hidden from Google. ⚠️ Why a Vercel Passcode Blocks Search Atlas Vercel's password protection (available on Pro and Enterprise plans) requires a browser-based authentication step. Because Search Atlas sends automated HTTP requests rather than using a browser session, it cannot pass this challenge. The crawler receives a 401 Unauthorized or redirect response and cannot proceed past the login wall. The solution is to remove the passcode gate for your staging subdomain and rely on noindex directives to prevent Google from indexing it instead. 🛠️ Recommended Setup: Open Staging + noindex Follow these steps to give Search Atlas full crawl access while keeping your staging content out of Google's index. 1. Remove the Vercel passcode from your staging deployment or create a dedicated staging subdomain (for example, staging.yourdomain.com) that has no password protection. 2. Add a noindex meta tag to every page on the staging environment. Place the following tag inside the <head> of your page template: <meta name="robots" content="noindex, nofollow"> 3. Block the staging subdomain in your staging robots.txt by adding the following rules to staging.yourdomain.com/robots.txt: - User-agent: * - Disallow: / Using both a noindex tag and a robots.txt Disallow provides two layers of protection against accidental indexing. 4. Verify the staging URL is not submitted to Google Search Console. Do not add your staging subdomain as a property in GSC, and do not include it in any production sitemap. 5. Add your staging site to Search Atlas. Go to Left sidebar → OTTO SEO, create a new project, and enter your staging subdomain URL. Search Atlas will now be able to crawl the site freely. 📊 Confirming Search Atlas Can Crawl Your Staging Site After completing the setup above, run a manual crawl to confirm everything is working: 1. Go to Left sidebar → OTTO SEO → Overview. 2. Select your staging project and click Scan. 3. Once the scan completes, navigate to Left sidebar → OTTO SEO → All Audits to review discovered pages and issues. 4. Use Left sidebar → OTTO SEO → Page Explorer to browse individual URLs and confirm your key staging pages are being indexed by Search Atlas (not by Google). If the crawl returns zero pages or shows access errors, double-check that the Vercel passcode has been fully removed for that deployment and that no IP allowlist or firewall rule is blocking external crawlers. 💡 Additional Tips - Use environment variables in your Vercel project to conditionally inject the noindex meta tag only when VERCEL_ENV equals preview or development. This prevents the noindex tag from accidentally appearing on your production build. - Separate projects in Search Atlas: Keep your production site and your staging site as separate OTTO SEO projects so audits and recommendations do not mix between environments. - Vercel preview deployments (the auto-generated .vercel.app URLs) are already set to noindex by Vercel by default on most plans, so you can point Search Atlas directly at those URLs without additional configuration — just make sure password protection is off. - If you use Vercel's GitHub integration for continuous deployment, remember that each new preview deployment generates a new URL. Update your Search Atlas project URL whenever you want to scan a specific deployment. 🔒 Quick Reference: Staging Checklist - Vercel passcode removed from staging deployment - noindex + nofollow meta tag added to all staging pages - robots.txt on staging subdomain set to Disallow: / - Staging subdomain not added to Google Search Console - Staging subdomain not included in production sitemap - Search Atlas OTTO SEO project created for staging URL - Manual scan completed successfully in Search Atlas If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⚡ Understanding Instant Indexing and Google Timelines

🔍 What Is Instant Indexing? Instant Indexing is a feature available on the Property plan that submits your URLs directly to Google's Indexing API. This signals Google to crawl and index those pages faster than standard organic discovery. However, the term "instant" refers to the speed of the submission request, not a guarantee that Google will index the page immediately after. ⏱️ Why Pages Can Still Take Time to Index Even after a successful Instant Indexing submission, Google retains full control over when and whether a page is actually indexed. Several factors influence this timeline: - Google's crawl queue: Google prioritises pages based on its own internal signals, including your site's crawl budget, domain authority, and historical crawl patterns. - Page quality signals: Pages that are thin, duplicated, or have technical issues may be deprioritised or skipped entirely. - Site authority: Newer or lower-authority domains typically experience longer indexing delays than established sites. - Server response times: If your server is slow or intermittently unavailable, Google may defer crawling. - Content freshness signals: Pages that are not frequently updated may receive fewer crawl visits overall. 📅 What Is a Realistic Indexing Timeline? While Instant Indexing can dramatically reduce the time Google takes to notice a page, it is not a bypass of Google's systems. Here is what most customers experience: - Best case: Some pages are crawled and indexed within a few hours of submission. - Typical case: Most pages are indexed within 24–72 hours of a successful submission. - Longer delays: Pages on newer sites, or those flagged for quality review by Google, may take one to two weeks or longer. Seeing pages listed as waiting to index after two days is within the normal range and does not indicate a problem with your plan or the submission itself. ✅ How to Check Your Submission Status You can verify that your URLs were submitted successfully within Search Atlas. A successful submission means the request reached Google — it does not confirm the page has been indexed yet. To verify actual indexing status, use Google Search Console or run a site: search in Google (e.g., site:yourdomain.com/your-page) to check whether the URL appears in Google's index. 🛠️ Steps to Improve Your Indexing Rate If pages are consistently slow to index, consider the following actions: 1. Ensure your pages meet Google's quality guidelines — avoid thin, duplicate, or low-value content. 2. Improve your site's crawlability — check for crawl errors in Google Search Console and resolve any blocking issues. 3. Build site authority — earning backlinks and publishing consistent, high-quality content helps Google prioritise your domain over time. 4. Check server performance — ensure your hosting environment responds reliably and quickly to Googlebot requests. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Understanding Developer-Level Site Audit Issues

What the Site Audit Checks The Search Atlas Site Audit scans your website for technical SEO problems across more than 80 categories, including crawlability, indexability, page speed, structured data, broken links, meta tags, and mobile usability. When the scan is complete, you receive a detailed report that flags every issue found, organized by severity and category. Some issues can be resolved directly within your content management system or through Search Atlas tools like OTTO SEO. Others involve the underlying code, server configuration, or architecture of your website — and those typically require a web developer to fix. Why Some Issues Need a Developer Search Atlas is a diagnostic and optimization platform. It can identify problems and, in many cases, apply fixes automatically through AI-driven tools. However, certain issues are rooted in areas that Search Atlas does not have the ability to modify: - Server configuration — redirect rules, .htaccess files, nginx settings, and response headers - Site architecture — URL structure, canonical tag logic, and faceted navigation - Custom-coded themes or plugins — hand-built templates, proprietary CMS setups, and legacy code - JavaScript rendering — client-side content that search engines struggle to crawl - Database-level problems — duplicate content generation, parameter-based URLs, and pagination logic In short, Search Atlas can tell you exactly what is wrong and why it matters for SEO, but applying the fix in these categories requires someone with access to your site's codebase or hosting environment. What Search Atlas CAN Fix Automatically Many common SEO issues do not require a developer. Search Atlas and OTTO SEO can address a wide range of on-page and technical optimizations, including: - Meta titles, meta descriptions, and header tag optimization - Internal linking suggestions and automated linking - Content gaps, keyword optimization, and topical coverage - Schema and structured data markup (in supported CMS environments) - XML sitemap generation and submission - Robots.txt recommendations If you are using OTTO SEO, many of these fixes are applied automatically as part of your ongoing optimization workflow. How to See Page-Specific Issue Details Every audit report in Search Atlas breaks issues down to the individual page level — not just a general summary. Here is how to find the specific pages affected: 1. Open your most recent Site Audit report. 2. Select any issue category from the report. 3. You will see a detailed list showing every specific URL affected by that issue, along with the detected problem for each page. When you encounter an issue that requires a developer, share the specific page-level details from your audit report with your development team so they have the exact URLs and issue descriptions needed to implement the 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.

🔍 Why Your Site Audit Is Taking Long

🕐 What Is a Normal Audit Duration? Most site audits complete within 10–45 minutes for small to medium static sites, with sites of a few dozen to a few hundred pages often finishing in 5–15 minutes. Large static sites with several thousand URLs typically take 1–3 hours, while JavaScript-rendered crawls usually take 12–24 hours (longer for very large sites). 📋 Common Reasons an Audit Takes Longer If your audit is taking significantly longer than usual — for example, an hour instead of five minutes — one or more of the following factors is likely the cause: - Large site size: Websites with a high number of pages, subdomains, or deeply nested URL structures require more time to fully crawl. - Slow server response times: If your web server responds slowly to requests, the crawler must wait longer at each page, extending the overall crawl time. - Crawl budget limits: Some servers throttle or rate-limit automated crawlers. Search Atlas respects these limits to avoid impacting your site's performance, which can slow the audit down. - Redirects and redirect chains: A high volume of redirects — especially chains of three or more hops — adds processing time at each URL. - JavaScript-heavy pages: Sites that rely heavily on client-side JavaScript rendering require additional processing per page. - Temporary server or network issues: Intermittent connectivity problems on your hosting provider's side can cause the crawler to pause and retry multiple times. - First-time or re-configured audit: If this is the first audit for a domain, or if settings were recently changed, the system performs a more thorough baseline crawl which takes longer. ✅ What You Can Do Right Now 1. Wait for the audit to complete. A longer crawl is not necessarily a failed one. If the progress indicator is still moving, the audit is still running. Give it additional time before taking action. 2. Check your site's availability. Open your website in a browser and confirm pages are loading normally. A site that is down or returning errors will cause the crawler to retry repeatedly. 3. Review your crawl settings. Navigate to your audit settings and confirm the crawl depth and page limit are appropriate for your site size. Reducing the crawl depth can significantly speed up future audits. 4. Avoid running multiple audits simultaneously. Triggering a new audit while one is already in progress can cause delays or conflicts. Wait for the current audit to finish first. 🔄 When to Restart an Audit If the audit has shown no progress for more than 60 minutes and your site is confirmed to be online and responsive, it is safe to cancel the current audit and start a new one. Note that audits stalled for more than 60 minutes are automatically detected and re-queued, and on a standard-sized site an audit still processing after 24–48 hours may be stuck. Use the same crawl configuration to ensure consistent results. 📊 Checking Site Health After the Audit Once your audit completes, you can review the full results under Left sidebar → Site Metrics (Site Explorer). This section gives you an overview of technical issues, page health scores, and crawl data that can help explain any slowdowns — such as a high number of redirect chains or server errors discovered during the crawl. 💡 Tips to Keep Future Audits Fast - Set a reasonable page crawl limit that matches your site's actual size. - Fix redirect chains — aim for direct 301 redirects with no more than one hop. - Ensure your robots.txt file is not accidentally blocking pages you want audited. - Keep your hosting server response time under 200ms where possible. - Schedule audits during off-peak traffic hours to avoid server throttling. 🛠️ Still Seeing Unusually Long Audits? If your audit consistently takes far longer than expected even after applying the steps above, our team can investigate whether there is a platform-side issue or a specific configuration problem with your domain. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Order Troubleshooting

Q: What is a broken link and why does it matter? A: A broken link points to a missing page (e.g., 404). Left unfixed, it wastes crawl budget, interrupts link equity, frustrates users, and can erode trust. Regular checks keep your site healthy and your rankings resilient. Q: What causes broken links, and how do I prevent them? A: Common causes include deleted/moved content, URL changes, typos, removed external resources, protocol/server issues, redirect chains/loops, and soft‑404s. Prevent issues by keeping URL structures stable, testing links before publishing, and running routine scans. Q: How do I find and fix broken links? A: Run scans with OTTO SEO or a Site Audit to identify errors and redirect chains. Then: fix typos, 301 redirect to the closest relevant page, restore removed content if appropriate, or ask external site owners to update broken backlinks. After fixes, monitor GSC crawl errors, bounce rates, organic traffic, and rankings for improvement. Q: How often should I scan for broken links? A: Large/fast‑changing sites: weekly to bi‑weekly. Smaller sites: monthly. All sites should run a comprehensive audit quarterly and within 48 hours after migrations or redesigns. Q: My links aren’t indexed, can you help? A: Yes. Share your Order ID and live URL(s) and we’ll submit them for indexing. Typical turnaround is 3–5 business days once we have the URLs, though final timing depends on search engines. We’ll notify you as soon as indexing is detected.

🔌 OTTO SEO Pixel Status Delay on Shopify

🧭 Overview After installing the OTTO SEO Pixel on your Shopify store, you may notice that the platform still shows the pixel as not installed — even though you followed every installation step correctly. This is expected behavior, not an installation error. During the initial site auditor crawl, pixel status updates are intentionally delayed. The crawl must complete before Search Atlas can confirm and reflect the pixel's active status. This process can take up to 24 hours. ⏳ Why the Delay Happens When you connect a Shopify store to Search Atlas, the platform automatically triggers a full site audit. The OTTO SEO Pixel status is verified as part of this crawl — it is not checked in real time at the moment of installation. Until the crawl finishes, the pixel status will remain in a pending or uninstalled state in the dashboard, regardless of whether the pixel code is correctly placed on your store. This is a known, expected part of the onboarding process and does not indicate that anything went wrong during installation. ✅ How to Confirm Your Pixel Is Installed Correctly Before waiting for the crawl to complete, verify that the pixel was added properly to your Shopify store by checking the following: - Log in to your Shopify admin panel and go to Online Store → Themes. - Click Actions → Edit Code on your active theme. - Open the theme.liquid file and confirm the OTTO SEO Pixel script is present just before the closing </head> tag. - Save the file if you made any changes. If the script is present and saved, your installation is complete. No further action is needed — the status in Search Atlas will update automatically once the site audit finishes. 📍 Where to Check Pixel Status in Search Atlas To monitor your pixel status and audit progress, navigate to OTTO SEO → All Sites (SEO Automation) using the left sidebar (URL: /seo-automation-v3). Your connected site and its current pixel status are displayed on this page. Once the initial crawl is complete, the status will automatically update to reflect that the pixel is active. 🕐 What to Do While You Wait The initial site audit typically completes within a few hours but may take up to 24 hours for larger Shopify stores with many pages. During this time: - Do not reinstall or remove the pixel script — doing so may reset the crawl timer. - Do not disconnect and reconnect your Shopify store, as this will trigger a new crawl from the beginning. - Check back on the OTTO SEO → All Sites (SEO Automation) page after a few hours to see if the status has updated. 🔁 If the Status Has Not Updated After 24 Hours If more than 24 hours have passed and your pixel status still shows as uninstalled, work through the following checks before reaching out for support: 1. Confirm the pixel script is still present in your theme.liquid file — theme updates or app installations can sometimes overwrite customizations. 2. Make sure you are checking the correct store — verify the domain shown in the OTTO SEO → All Sites (SEO Automation) section matches your active Shopify store URL. 3. Clear your browser cache and reload the OTTO SEO → All Sites (SEO Automation) page to rule out a display issue. 4. If a theme update was applied after installation, re-add the pixel script to the updated theme and allow another crawl cycle to complete. If the status still does not update after confirming all of the above, our support team can investigate the crawl logs and pixel detection directly. 💬 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.

🔍 Site Audit Project Limits and Plan Upgrades

🗂️ Understanding Site Audit Project Limits Each Search Atlas plan includes a set number of Site Audit projects you can run at one time. These limits apply to the number of active projects in your account, not the number of pages crawled per audit. Here is a general breakdown of project limits by plan tier: - Starter: Limited number of concurrent Site Audit projects - Pro: Up to 100 active Site Audit projects - Enterprise: Custom limits tailored to your team's needs If your dashboard shows 100 projects and you believe you were promised a different amount, this article will help you understand why and what your options are. ⚙️ Why Your Dashboard May Show 100 Audits on Pro The Pro plan includes up to 100 active Site Audit projects by default. This is not a bug or an error — it reflects the standard project allocation for your current plan. If you were told you have unlimited Site Audits, this may have referred to unlimited page crawls within a single audit project, or it may have been a miscommunication during the sales process. The project count cap (how many separate websites or audits you can run simultaneously) is a separate limit from crawl depth. Key distinction to keep in mind: - Project limit: How many individual Site Audit projects you can create and run (e.g., 100 on Pro) - Crawl limit: How many pages are crawled within a single audit project (varies by plan) 🚀 How to Add More Site Audit Projects If you have reached your project limit and need to add more, you have two options: 1. Upgrade to Enterprise: Enterprise plans offer custom project limits designed for agencies and large teams managing many websites. Pricing is tailored to your specific usage requirements. 2. Delete inactive projects: If some of your existing Site Audit projects are no longer needed, you can delete them to free up slots within your current plan. To delete an existing Site Audit project and free up a slot, follow these steps: 1. Log in to your Search Atlas account. 2. Navigate to Site Explorer in the left sidebar. 3. Locate the Site Audit project you want to remove. 4. Open the project settings and select Delete Project. 5. Confirm the deletion. The slot will become available immediately. 💡 Escalating to an Enterprise Plan If your team manages a high volume of websites and 100 projects is not sufficient, an Enterprise plan may be the right fit. Enterprise plans include: - Custom Site Audit project limits beyond the standard 100 - Dedicated onboarding and account support - Flexible pricing based on your team's scale - Access to advanced features and higher usage thresholds across the platform To discuss Enterprise pricing and get a custom quote, reach out directly through the platform's live chat so our team can review your account and provide accurate figures. ❓ Frequently Asked Questions Does deleting a project remove my historical audit data? Yes. Deleting a Site Audit project permanently removes all crawl history and reports associated with it. Make sure to export any data you need before deleting. Can I temporarily pause a project instead of deleting it? Currently, Site Audit projects cannot be paused. You can stop scheduled crawls, but the project will still count toward your active project limit. Will my project limit increase automatically if I upgrade my plan? Yes. Once your plan upgrade is confirmed, your new project limit will be reflected in your dashboard immediately. 🛠️ 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.

🌐 Adding Multilingual Websites to Search Atlas

🗺️ Overview If your website serves multiple languages or regions, the URL you add to Search Atlas determines which version of your site is tracked, analysed, and optimised. Adding the wrong URL means your rankings, keywords, and site data will reflect the wrong language or audience. This article explains how to choose the correct URL for your goals. 🧠 The Core Principle: Match the URL to Your Target Search Atlas tracks SEO performance for the exact URL you add. For multilingual sites, each language or regional version typically lives at a distinct URL — either a subdirectory, subdomain, or separate domain. You should add the URL that matches the language and geographic audience you want to rank for. - Root domain (e.g. example.com) — tracks the default language version, usually English. - Subdirectory (e.g. example.com/es/) — tracks a specific language version hosted under the main domain. - Subdomain (e.g. es.example.com) — tracks a language version hosted on a subdomain. - Country-code top-level domain (e.g. example.com.pe) — tracks a version targeting a specific country. Each of these URLs is treated as a separate property in Search Atlas, so add the one that directly represents the version you are optimising. 📌 Practical Example: English Root and Spanish Subdirectory Suppose your site has two versions: - example.com — English, targeting a global or US audience. - example.com/es/ — Spanish, intended to rank in Peru. If your goal is to rank the Spanish version in Peru, you should add example.com/es/ to Search Atlas — not the root domain. Adding the root domain would give you data for the English version only, and you would miss the keyword rankings, traffic, and on-page insights specific to your Spanish content. ➕ How to Add Your Language-Specific URL 1. In the left sidebar, click Site Metrics (Site Explorer). 2. On the Site Explorer page, locate the input field to add a new website. 3. Enter the full subdirectory URL, for example https://example.com/es/. Include the trailing slash if your site uses one. 4. Confirm and save. Search Atlas will begin pulling data specifically for that URL and its child pages. Once added, you can use tools such as Rank Tracker (left sidebar → Keywords → Rank Tracker) to track Spanish keyword rankings and set the target location to Peru, and Keyword Magic (left sidebar → Keywords → Keyword Magic) to research Spanish-language keywords relevant to a Peruvian audience. 🌍 Setting the Right Geographic Target Adding the correct URL is the first step. To get accurate ranking data for Peru specifically, you also need to configure the location and language settings within each tool: - In Rank Tracker, when adding keywords, set the country to Peru and the language to Spanish. This ensures rank positions reflect real search results seen by users in Peru. - In Keyword Magic, filter keyword data by selecting Peru as the target country so search volume and difficulty figures are localised. Without setting the geographic target, ranking data may default to a global or US baseline, which will not accurately represent your performance in Peru. 📋 Quick Reference: Which URL Should I Add? - Goal: rank the English root site globally → Add example.com - Goal: rank the Spanish subdirectory in Peru → Add example.com/es/ - Goal: rank a Spanish subdomain → Add es.example.com - Goal: track both versions separately → Add each URL as a separate property in Site Explorer You can add multiple URLs to Search Atlas to monitor all language versions in parallel. There is no requirement to choose only one. ⚠️ Common Mistakes to Avoid - Adding only the root domain when targeting a subdirectory version. The root domain will not surface ranking data for pages that live under /es/. - Forgetting to set location in Rank Tracker. Even with the correct URL added, rank data defaults to a broad location unless you specify Peru. - Using inconsistent URL formats. Make sure the URL you add matches exactly how your site is structured — check whether it uses a trailing slash and whether it is HTTP or HTTPS. 💬 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.

🔍 Site Audit Metrics, Rankings, and FAQ Schema Explained

🗺️ Overview This article answers three of the most common questions about the Site Audit tool: how to track keywords inside your audit report, what the page-level metrics mean, and why Google may be detecting FAQ schemas you did not manually create. ➕ How to Add Keywords to Your Site Audit Report Site Audit page metrics are more meaningful when keyword data is attached to each page. Follow these steps to connect keywords to your audit: 1. Go to Left sidebar → Keywords → Rank Tracker and confirm the keywords you want to track are already added to your project. If they are not, add them there first. 2. Return to Left sidebar → Site Metrics (Site Explorer) and open your target site. 3. Inside the Site Audit report, navigate to OTTO SEO → Site Audit → Page Explorer. Each page will display its associated ranking keyword if one has been matched from your Rank Tracker list. 4. To research additional keyword opportunities before adding them, use Left sidebar → Keywords → Keyword Magic to find relevant terms, or use Left sidebar → Keywords → Keyword Gap to identify keywords your competitors rank for that you do not. 5. Once you add new keywords to Rank Tracker, the Site Audit report will reflect the updated keyword-to-page mapping on the next scheduled crawl or when you manually trigger a re-crawl. Tip: Assign one primary keyword per page for the clearest performance data. Pages without a matched keyword will still show technical metrics but will not display ranking position data. 📊 What the Page Metrics Show Each page in your Site Audit report includes a set of metrics that help you evaluate both technical health and search performance. Here is what the key metrics mean: - Health Score — A 0–100 score reflecting the overall technical condition of the page. Issues such as missing meta tags, slow load time, or broken links reduce this score. - Ranking Position — The current Google search position for the page's matched keyword, pulled from Rank Tracker data. - Impressions & Clicks — Data sourced from your connected Google Search Console property, showing how often the page appears in search results and how often users click through. - Page Speed — A performance indicator based on Core Web Vitals signals. Pages flagged here may benefit from image compression or script optimisation. - Issues Count — The total number of detected on-page or technical SEO issues. Click the count to drill into a categorised list of what needs fixing. - Schema Detected — The structured data types Google has found on the page, which may include types added by plugins, themes, or your CMS automatically. Metrics refresh each time the site is crawled. You can trigger a manual re-crawl at any time from the Site Audit dashboard. ❓ Why Is Google Detecting FAQ Schema I Didn't Set Up? This is a common source of confusion. Seeing FAQ schema listed under Schema Detected does not always mean you added it intentionally. Here are the most frequent reasons it appears: - WordPress plugins — Plugins such as Yoast SEO, Rank Math, or All in One SEO can automatically generate FAQ schema from accordion blocks or question-and-answer formatted content on your page. - Page builder blocks — Builders like Elementor, Divi, or Gutenberg include FAQ block types that inject structured data by default when used. - Theme features — Some premium themes include built-in schema markup for common content patterns, including FAQs, without requiring any manual configuration. - CMS or e-commerce platforms — Platforms like Shopify or Wix may add schema automatically to product pages or help content. If you want to verify exactly where the schema is coming from, use Google's Rich Results Test (search.google.com/test/rich-results) and paste your page URL. The tool will show detected schema and flag the source code location. You can then trace it back to the plugin, block, or theme generating it. Is the FAQ schema a problem? Not necessarily. Valid FAQ schema that matches the page content can improve your appearance in Google Search with rich results. However, if the schema is inaccurate or does not reflect real content on the page, you should remove or correct it to avoid a Google manual action. 🛠️ Quick Troubleshooting Checklist - Keywords not showing on pages → Confirm they are added in Rank Tracker first, then re-crawl. - Metrics look outdated → Trigger a manual re-crawl from the Site Audit dashboard. - Unexpected schema detected → Use Google's Rich Results Test to identify the source plugin or theme. - Health Score is low → Click the Issues Count on the affected page for a prioritised fix list. - No impressions or clicks data → Check that Google Search Console is connected to your Search Atlas project under project settings. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. Additional Notes The Site Audit report does not have a field where you manually add keywords. Organic Keywords = terms Google currently ranks your pages for; Paid Keywords = terms with active paid ads. These update automatically and cannot be manually edited — they reflect live data, not a custom list.

🛠️ Fix Audits, Keywords & Location Recommendations

🔍 Overview This article walks you through four common project setup tasks: excluding specific URL paths from your site audit, rerunning the crawl to apply those changes, importing keywords with competitor insights, and understanding why a location may not be generating recommendations. 🚫 Excluding URLs from Your Site Audit If your project is crawling pages you don't want audited — such as /obituaries/ or /store/ — you can exclude them by URL path before or after the initial crawl. 1. Open your project and navigate to the Site Audit section. 2. Click Settings or Project Settings near the top of the page. 3. Locate the Exclude URLs or Crawl Exclusions field. 4. Enter the paths you want to exclude, one per line. For example: /obituaries/ and /store/. You can use partial path matches — any URL containing that string will be excluded. 5. Save your settings before proceeding. Tip: Use a forward slash at the start and end of each path segment (e.g., /store/) to ensure accurate matching and avoid unintended exclusions. 🔄 Rerunning the Crawl After Exclusions Exclusion rules only apply to future crawls. After saving your exclusions, you must rerun the audit to see updated results. 1. Return to the main Site Audit dashboard for your project. 2. Click the Recrawl or Rerun Audit button — this is usually found in the top-right area of the audit view. 3. Confirm the action when prompted. The crawl will restart and apply your new exclusion rules from the beginning. 4. Wait for the crawl to complete. Depending on your site size, this may take a few minutes to an hour. Once the crawl finishes, any URLs matching your excluded paths will no longer appear in your audit results or issue counts. 📊 Tracking Keywords and Importing Competitor Insights You can add keywords to your project for rank tracking and enrich them with competitor data at the same time. 1. In the left sidebar, click Site Metrics → Keywords to open the Keywords page. 2. Search for your target keywords or enter them manually. 3. Select the keywords you want to track by checking the boxes next to them. 4. Click Add to and assign them to a keyword list or Rank Tracker. 5. To import competitor keyword insights, use the Competitor Gap or Competitor Analysis feature within the same tool. Enter a competitor domain to surface keywords they rank for that you may be missing. 6. Select the competitor keywords you want to import and add them to your tracking list using the same process above. Once added, your tracked keywords will appear in the project's keyword dashboard, and ranking data will begin populating within 24 hours. 📍 Why One Location Isn't Generating Recommendations If you have multiple locations set up and one is producing recommendations while another shows none, there are a few common causes to check. - Insufficient local data: Search Atlas generates location-based recommendations using local search data. If the target location has low search volume or limited data coverage, the system may not have enough signals to produce recommendations. - Location not fully configured: Confirm that the location has a complete address, a linked Google Business Profile (if applicable), and the correct target language and country set in its settings. - Crawl not yet completed for that location: Each location may require its own crawl or content scan. Check whether the location's audit status shows Complete or is still Pending. - No tracked keywords assigned to that location: Recommendations are often tied to the keywords being tracked. Make sure keywords are assigned to the specific location, not just to the overall project. - OTTO SEO V3 not enabled for that location: In the left sidebar, click OTTO SEO → SEO Automation (SEO Automation) (URL: /seo-automation-v3) and verify that the location in question has OTTO SEO V3 activated. If it is toggled off, no recommendations will be generated. If the location is correctly configured and the crawl is complete but recommendations are still not appearing after 24–48 hours, it is worth reviewing whether the location's primary keyword set has enough search data to trigger the recommendation engine. ✅ Quick Checklist - URL exclusions saved in project settings before rerunning the crawl - Crawl rerun after exclusions to apply changes - Keywords added to tracking and competitor keywords imported - Problem location has a complete profile, active crawl, assigned keywords, and OTTO SEO V3 enabled 💬 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.

🔄 How to Recrawl and Reprocess Your Website Audit

This article explains how to initiate a recrawl of your website and trigger a manual reprocess of your audit data in Search Atlas. Use these steps when your audit results feel outdated, changes you've made aren't reflected, or you want to force a fresh analysis of your site. 🛠️ Step-by-Step 1. Log in to your Search Atlas account and navigate to your project's site audit area. Depending on your plan and setup, this is typically accessible from your main project dashboard. 2. Open the audit report for the website you want to recrawl. Look for the site or domain you wish to update in your project list. 3. Navigate to OTTO SEO → Site Audit → Overview (Website Overview) and locate the Recrawl Site button. This is usually represented by a refresh button near the top of the audit report page, often next to the last crawl date or crawl status indicator. 4. Click the recrawl button to initiate a new crawl. The platform will begin re-scanning your website pages. Crawl time varies depending on your site's size — larger sites may take several minutes to complete. 5. Once the crawl has finished, locate the Reprocess option. This step re-analyzes the newly collected crawl data and updates all audit scores, issue counts, and recommendations. The reprocess button is typically found in the same audit controls area, often labeled Reprocess or Recrawl Site. 6. Click Reprocess (or its equivalent) to trigger the manual reprocessing. Wait for the platform to confirm the reprocess has completed before reviewing your updated results. ✅ How to Confirm It Worked After completing both steps, confirm the recrawl and reprocess were successful by checking the following: - The Last Crawled or Last Updated timestamp on your audit report should reflect today's date and the approximate time you initiated the recrawl. - Your audit scores, issue counts, and page-level data should reflect any changes you made to your site since the previous crawl (for example, fixed issues should no longer appear as errors). - If a progress bar or crawl status indicator was visible during the process, it should now show a Completed or Done status rather than a pending or in-progress state. - If issue counts or scores appear unchanged and the timestamp has not updated, wait a few minutes and refresh the page, as large sites may take additional time to fully reprocess. If you need further assistance, open 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 Indexing Timeline and Best Practices

🔍 Overview After publishing a cloud stack in Search Atlas, you may notice that your pages are not yet appearing in Google's search results — even after several weeks. This is completely normal. Indexing is controlled entirely by Google, not by Search Atlas. This article explains what to expect and what steps you can take to encourage faster indexing. ⏱️ How Long Does Indexing Take? There is no fixed timeline for Google to index a newly published cloud stack. However, here are general benchmarks to keep in mind: - Typical timeline: Most cloud stack pages begin indexing within a few weeks of publication. - Extended timeline: In some cases, indexing can take six weeks or longer. A wait of around one to two months is within the normal range and does not indicate an error. - No guarantee: Google does not index every page it discovers, and the pace at which it crawls new content varies based on your site's overall authority, crawl budget, and the signals pointing to the page. If your cloud stack has not indexed after several weeks, it does not mean something has gone wrong — but there are proactive steps you can take to improve the chances of indexing. 🗺️ Where to Find Your Cloud Stacks You can review your published cloud stacks and their associated URLs inside the Search Atlas platform. Search Atlas also provides a URL Indexer tool that allows you to submit specific URLs for indexing consideration. Refer to the in-platform navigation or reach out to our support team if you need help locating these sections. ✅ Best Practices to Encourage Indexing While Google ultimately decides when and whether to index a page, the following actions send strong signals that your content is valuable and worth crawling. Apply as many of these as possible after publishing a cloud stack. 1. Submit to Google Search Console: Open Google Search Console, paste the cloud stack URL into the URL Inspection tool, and click Request Indexing. This is the most direct signal you can send to Google and should always be your first step. 2. Add internal links: Link to your cloud stack URL from existing pages on your main website — for example, from blog posts, service pages, or your homepage. Internal links help Google discover and prioritise new pages. 3. Mention it in a blog post: Publish a blog post on your website that references or links directly to the cloud stack. Fresh content with outbound links accelerates discovery. 4. Share on social media: Post the cloud stack URL on your social media profiles (LinkedIn, X/Twitter, Facebook, etc.). Social signals and external clicks indicate to Google that the content exists and is being engaged with. 5. Earn or build backlinks: Seek opportunities to have other relevant websites link to your cloud stack URL. If you need further assistance, open 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 Crawl Settings and Analysis Timeline

🗺️ Overview When running a Site Audit in Search Atlas, two settings have a direct impact on the quality of your results and how long the audit takes: user agent and crawl speed. Choosing the wrong user agent can reduce page capture accuracy, while an uncalibrated crawl speed may strain your server. This article also clarifies realistic timelines so you know when to expect your audit to finish. 🤖 Choosing the Right User Agent The user agent tells the Site Auditor how to identify itself when crawling your pages. Search Atlas offers several options, and selecting the correct one affects how accurately your pages are rendered and captured. Recommended user agent: Chrome Desktop - Chrome Desktop — The best choice for most sites. It renders pages the way a real browser does, capturing JavaScript-dependent content, Open Graph tags, and dynamic elements accurately. Use this for the most complete and reliable audit results. - Search Atlas Bot — A lightweight crawler that does not render JavaScript. It is faster but will miss dynamically loaded content, metadata, and tags generated client-side. This is not recommended if your site relies on JavaScript rendering. - Googlebot — Mimics Google's crawler. Useful if you specifically want to see how Googlebot views your site, but Chrome Desktop remains the better general-purpose choice. If your previous audits used Search Atlas Bot and returned incomplete Open Graph or metadata results, re-run the audit with Chrome Desktop selected to get a fuller picture of your site's issues. 🚀 Optimising Crawl Speed Crawl speed controls how many pages per second the auditor requests from your server. For most sites — particularly those on shared hosting or with limited server resources — a lower speed is recommended to reduce the risk of overloading your server and to help ensure the audit completes without triggering rate limits or returning incomplete data. - If your site is large and hosted on a dedicated or enterprise-grade server, you may use a higher crawl speed setting. - If you notice server errors or timeouts during a crawl, reduce the speed further to a lower value. To adjust crawl speed, open your Site Audit settings before starting or re-running a crawl and update the crawl speed to your preferred value before launching the audit. ⏱️ How Long Does a Site Audit Take? Site Audit analysis time depends on the size of your site and the crawl speed you have selected. Larger sites and lower crawl speeds will naturally require more time to complete. If your audit appears stuck in analysis, check that your crawl speed is appropriately set for your server capacity and consider re-running the audit with Chrome Desktop as the user agent for the most reliable 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.

📊 Understanding and Managing Site Audit Quotas

🔍 Overview Site audit quotas in Search Atlas work differently from other usage limits in your account. Instead of appearing in the general quota panel, site audit credits are tracked and managed in their own dedicated section. This article explains where to find your site audit usage, how the quota system works, and how to purchase additional audits when needed. 📍 Where to Find Your Site Audit Quota Your site audit usage is not displayed in the main quota or usage panel — this is intentional, as site audits are managed as a standalone resource. To view your current site audit quota and usage, follow these steps: 1. Log in to your Search Atlas account. 2. Navigate to Site Metrics → Site Explorer using the left sidebar. 3. From the Site Explorer section, open any active site project or initiate a new site audit. 4. Your remaining audit credits and usage details will be displayed within the site audit interface for that project. Because site audit credits are project-based and separate from keyword or AI content quotas, they will never appear in the general plan usage panel. This is expected behaviour, not a bug. 💡 Why Site Audits Have a Separate Quota Site audits consume significant computing resources — crawling thousands of pages, analysing technical issues, and generating actionable recommendations. For this reason, Search Atlas tracks site audit usage independently so you always have a clear, accurate picture of your crawl capacity without it being mixed in with other feature limits. Key things to know about site audit quotas: - Monthly reset: Audit credits reset at the start of each billing cycle, in line with your current plan. - Per-crawl consumption: Each full site crawl deducts from your quota based on the number of pages crawled. - Plan-based allocation: The number of audit credits included each month depends on your subscription tier. 🛒 How to Purchase Additional Site Audit Credits If you have used your monthly allocation and need to run more audits before the next reset, you can purchase additional credits directly inside the platform: 1. Click your Avatar in the top-right corner. 2. Select Billing → Plans & Top-ups. 3. Look for the Site Audit Credits add-on option. 4. Choose the number of additional credits you need and complete the purchase. Additional credits purchased as add-ons are available immediately after checkout and do not roll over to the following billing cycle — use them before your next reset date. ✅ Quick Troubleshooting If something does not look right with your site audit quota, check the following before contacting support: - Quota panel shows nothing for site audits: This is normal — site audit credits are not displayed in the general quota panel. Check usage directly inside the Site Explorer section. - Credits appear lower than expected: A large site crawl (many pages) will consume more credits. Review your crawl settings to limit scope if needed. - Credits did not reset on time: Allow up to 24 hours after your billing cycle renews. If the issue persists after that window, reach out via the chat widget. - Purchase not reflecting: Refresh the page and clear your browser cache. If credits still do not appear, 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.

Site Audit Quota Visibility and Display Issues

Overview If you open your account's usage or quota section and do not see a Site Audit line item, this is not necessarily a bug. Site Audit quota visibility depends on your current plan. This article explains what to check and how to add a Site Audit quota to your subscription if you need one. Why Site Audit Quota May Not Appear Not all plans include a standalone Site Audit quota. If your current plan does not include Site Audit as a separately allocated entitlement, no Site Audit usage line will appear in your account's usage section. This is expected behavior and does not indicate a technical problem. How to Check Whether Your Plan Includes a Site Audit Quota 1. Open the top-right Avatar Menu (👤) and click Billing (the Billing page). Look for a list of your current plan's included features or entitlements. 2. Look for a Site Audit entry. If Site Audit is listed as part of your plan with a defined limit, it should be reflected in your usage view once activity has occurred. If it is not listed, your plan does not currently include a standalone Site Audit allocation. How to Add or Upgrade a Site Audit Quota 1. Navigate to the Billing page by clicking the top-right Avatar Menu (👤) and selecting Billing within the Search Atlas platform. 2. Review available plan options or add-ons. Look for plans or add-ons that list Site Audit as an included or upgradeable feature. 3. Select the plan or add-on that includes Site Audit and complete the upgrade or purchase process. Once your subscription is updated, your Site Audit allocation will be reflected in your account. 4. If you do not see an option to add a Site Audit quota from your billing settings, or if you are unsure which plan to choose, contact the support team directly for guidance on the right option for 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.

🗺️ Migrate Sitemap Exclusion Settings From Yoast

🔍 Overview When switching from Yoast SEO to Search Atlas, one common step is recreating your sitemap exclusion rules. In Yoast, you can toggle off specific post types and taxonomies — such as author pages, category pages, and tag pages — so they are excluded from the XML sitemap. Search Atlas gives you the same control through its sitemap settings inside the WordPress plugin. This article explains what to prepare and how to get the right settings configured. ⚙️ Before You Begin Make sure the following prerequisites are in place before adjusting sitemap settings: - The Search Atlas WordPress plugin is installed and activated on your site. - You are logged in to your WordPress admin dashboard. - You have already deactivated Yoast SEO (or at minimum disabled the Yoast sitemap feature) to avoid duplicate sitemaps conflicting with each other. - You have a note of which URL types were excluded in Yoast — check your old Yoast settings under Yoast SEO → Search Appearance → Content Types and Taxonomies before fully removing the plugin. 🛠️ How to Exclude URL Types From Your Sitemap in Search Atlas To replicate your Yoast sitemap exclusion rules inside the Search Atlas plugin, follow these general steps: 1. Log in to your WordPress admin dashboard. 2. In the left-hand menu, click Search Atlas to open the plugin settings. 3. Navigate to the Sitemap section within the plugin. 4. Within the sitemap settings, locate the controls for post types (e.g. author pages, custom post types) and disable or exclude each type you do not want included in your sitemap. 5. Similarly, locate the controls for taxonomies (e.g. category pages, tag pages, custom taxonomies) and disable or exclude each one you want removed from the sitemap. 6. Save your settings once all exclusions are configured. 7. After saving, verify your sitemap by visiting yoursite.com/sitemap.xml and confirming that the excluded URL types no longer appear. The exact names of controls and settings may vary depending on your plugin version. If you cannot locate the relevant options, reach out to our support team with your plugin version number and a description of which URL types you need to exclude. 📋 Common Yoast Exclusions and Their Search Atlas Equivalents Use the table below as a quick reference when recreating your exclusions: - Yoast: Author archives set to "noindex" → Search Atlas: Find the author pages or author archives option within the sitemap settings and disable it. - Yoast: Categories excluded from sitemap → Search Atlas: Find the categories option under the taxonomy-related sitemap controls and disable it. - Yoast: Tags excluded from sitemap → Search Atlas: Find the tags option under the taxonomy-related sitemap controls and disable it. - Yoast: Custom post type excluded → Search Atlas: Find the corresponding custom post type within the sitemap settings and disable it. If you are unsure which settings correspond to your specific Yoast exclusions, have the following ready when contacting support: your plugin version, the URL types you need to exclude, and a screenshot or description of what you currently see in the Search Atlas sitemap 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.

🗺️ Disabling URL Types in Sitemap Settings

🔍 Overview When you import sitemap settings from a plugin like Yoast SEO, Search Atlas does not automatically carry over your exclusion rules. URL types that were disabled in Yoast — such as author pages, video pages, category pages, and tag pages — may appear as enabled in Search Atlas and surface as sitemap errors. This article explains how to locate and disable those URL types directly inside Search Atlas. ⚙️ How Sitemap URL Type Settings Work in Search Atlas Search Atlas manages its own sitemap configuration independently of any third-party SEO plugin. Even if a URL type was excluded in Yoast before migration, Search Atlas may not reflect those exclusions automatically. You will need to review and update these settings after any import or plugin migration. 🛠️ How to Disable Specific URL Types 1. Log in to your Search Atlas account and make sure the correct project (website) is selected. 2. Navigate to the sitemap settings area within your project. If you are unsure where to find this, reach out to our support team for exact navigation steps — the location may vary depending on your account setup. 3. Locate the URL type controls for your sitemap. You should see options corresponding to different URL types that Search Atlas can include — such as posts, pages, categories, tags, authors, and video sitemaps. 4. Find the URL type you want to exclude (e.g., Author, Category, Tag, or Video). 5. Disable or turn off that URL type using the available control. 6. Repeat for each URL type you want to exclude. 7. Save your changes so that the excluded URL types are removed from your sitemap. 📋 Common URL Types to Disable After a Yoast Migration If you previously excluded any of the following in Yoast, check each one in your Search Atlas sitemap settings and disable as needed: - Author pages — Archive pages automatically generated for each author on your site. - Category pages — Taxonomy archive pages for post categories. - Tag pages — Taxonomy archive pages for post tags. - Video sitemap — A separate sitemap index for video content embedded on your pages. Leaving these enabled when they were previously excluded can cause sitemap errors and may send search engines to thin or duplicate content pages, which can negatively affect your crawl budget and indexing. ✅ Verifying Your Sitemap After Changes After saving your updated settings, it is good practice to verify that the excluded URL types no longer appear in your sitemap. You can do this by: - Opening your sitemap URL directly in a browser (e.g., yourdomain.com/sitemap.xml) and confirming the excluded URL types are not listed. - Using the sitemap preview or validation tools available within Search Atlas to confirm the updated sitemap reflects 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.

🔄 Syncing Site Audit with OTTO and Search Atlas Changes

🧭 Overview Site Audit and OTTO are two separate tools that collect and display data differently. If you have made changes inside Search Atlas or applied OTTO optimizations but your Site Audit still shows the same errors after several days, it does not mean the tool is broken. It means a few important steps may be missing before those changes can appear in your audit results. This article explains how Site Audit and OTTO work together, what causes the disconnect, and exactly what to do to get your audit results up to date — including resolving Google Rich Results errors and CORS policy errors. 🔍 Why Site Audit and OTTO Show Different Results Site Audit crawls your live website to detect technical issues. It reads what is actually published and accessible on your domain at the time of the crawl. OTTO, on the other hand, generates and stages optimizations inside Search Atlas. OTTO changes are not live on your website until you explicitly publish them. If optimizations remain in a staged or draft state, your live site is unchanged, and Site Audit will continue to report the same errors it found on the previous crawl. This is the most common reason customers see no improvement in Site Audit results after working in OTTO for multiple days. ✅ Step 1 — Confirm Your OTTO Changes Are Published 1. Go to Left sidebar → OTTO SEO → SEO Automation (URL: /seo-automation-v3). 2. Review your list of OTTO optimizations and check the status of each item. 3. Any optimization showing a staged, pending, or draft status has not been pushed to your live site yet. 4. Select the optimizations you want to apply and click Publish (or the equivalent deploy action shown in the UI). 5. Wait for confirmation that the changes have been successfully pushed before moving to the next step. Important: Skipping this step means your live website never received the changes. Site Audit will keep reporting the same issues no matter how many times it recrawls. 🕷️ Step 2 — Trigger a New Site Audit Crawl Site Audit does not automatically detect that changes were made. After you have confirmed your OTTO optimizations are published to your live site, you must manually start a new crawl so the audit can pick up the updated state of your pages. 1. Navigate to your Site Audit dashboard inside Search Atlas. 2. Locate the project for the domain you updated. 3. Use the available option in the interface to launch a fresh crawl for that project. 4. Wait for the crawl to complete. Depending on the size of your site, this may take several minutes to a few hours. 5. Once the crawl finishes, review the updated results. Previously flagged errors that were correctly fixed should now be resolved. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🗑️ Remove OTTO Pixel Linkage to Delete Site Audit Projects

🔍 Understanding the Two Separate Issues If you cannot delete a Site Audit project, there are two distinct problems that can block you — and they require different solutions. Confusing them leads to wasted effort. - OTTO pixel linkage (primary blocker): A Site Audit project tied to an OTTO pixel cannot be deleted until that pixel link is removed. This is true even if the OTTO session is inactive. - 5-project cap (secondary constraint): Your plan limits you to five active Site Audit projects. Deep Freeze can help preserve projects without counting against this cap — but only after the OTTO linkage is resolved. Deep Freeze does not remove pixel linkage and will not unblock deletion on its own. If your projects named canary, armbarmarketing, or any other project refuse to delete, resolve the OTTO linkage first using the steps below. ⚙️ Step 1 — Locate the Linked OTTO Pixel 1. In the left sidebar, click OTTO SEO and then open SEO Automation inside it (/seo-automation-v3). 2. Review all OTTO sessions listed, including inactive ones. An inactive session still holds its pixel link to the Site Audit project. 3. Identify the session whose pixel corresponds to the project you want to delete. The session name or connected domain will match the Site Audit project name. 🔓 Step 2 — Unlink or Delete the OTTO Pixel You have two options depending on whether you want to keep the OTTO session or remove it entirely. Option A — Delete the entire OTTO session (recommended if you no longer need it): 1. Inside OTTO SEO V3, locate the OTTO session linked to the project you want to remove. 2. Open the session settings or the three-dot menu next to the session. 3. Select Delete Session and confirm. This removes the pixel and severs the link to the Site Audit project. Option B — Unlink the pixel while keeping the OTTO session: 1. Inside the OTTO session, navigate to the Pixel / Tracking settings section. 2. Find the pixel currently linked to the Site Audit project. 3. Select the option to Disconnect or Unlink the pixel from the project. 4. Save your changes. After completing either option, the Site Audit project is no longer protected by the pixel link. 🗑️ Step 3 — Delete the Site Audit Project 1. In the left sidebar, go to Site Metrics → Site Explorer to open the projects list (/site-explorer/list). 2. Locate the project you want to remove (for example, canary or armbarmarketing). 3. Open the three-dot menu or settings icon next to the project. 4. Select Delete Project and confirm. The option should now be available because the OTTO pixel link has been removed. 📦 Step 4 (Optional) — Use Deep Freeze to Manage the 5-Project Cap Once OTTO linkage is no longer blocking your projects, you can use Deep Freeze to stay within the 5-project cap without permanently deleting projects you want to keep. - Deep Freeze preserves a project's existing data and pauses crawling so the project does not count as an active slot. - Use this for projects you want to return to later rather than delete. - Important: Deep Freeze does not resolve OTTO pixel linkage. Always unlink the pixel first if deletion is your goal. ✅ Quick Reference — Which Solution Fixes Which Problem - Cannot delete a project → Unlink or delete the associated OTTO pixel (Steps 1–3 above). - Hit the 5-project cap → Delete unwanted projects (after unlinking pixels) or Deep Freeze projects you want to keep. - Deep Freeze alone → Does not unblock deletion. It only frees an active slot for projects that are not pixel-locked. 💬 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 Audit Blocked Competitor Domains Explained

🔍 Overview When running a Site Audit on a competitor's domain, you may occasionally find that the audit cannot complete or returns an error. This is not a bug in Search Atlas — it is caused by the competitor's website actively blocking the audit crawler. This article explains why this happens and what steps you can take. 🚧 Why Some Competitor Domains Are Blocked Many large websites use a content delivery network (CDN) called Amazon CloudFront to serve their content and protect their infrastructure. CloudFront includes security rules that can detect and block automated crawlers, including the Search Atlas Site Audit bot. When a domain has these protections active, our crawler is denied access before it can gather any data. This is a deliberate security decision made by the website owner — it is entirely outside Search Atlas's control. ⚙️ What Happens During a Blocked Audit If you attempt to audit a competitor domain that is protected by CloudFront or a similar security layer, the audit may fail to return meaningful data. This outcome does not indicate a problem with your Search Atlas account or project setup — it reflects the competitor's server actively rejecting crawler access. ✅ What You Can Do While you cannot force access to a domain that actively blocks crawlers, there are several productive steps you can take: 1. Confirm the block is on their end. Try accessing the competitor's sitemap directly in your browser (e.g., example.com/sitemap.xml). If it loads normally for you but the audit fails, the block is targeting automated tools specifically. 2. Use alternative competitor research tools within Search Atlas. Other tools in the platform rely on Search Atlas's existing index rather than live crawling, meaning they are not affected by the competitor's crawler-blocking configuration. Explore the available research and analysis features to gather competitor intelligence without needing to crawl their domain directly. 3. Monitor the domain over time. Security configurations change. You can retry the Site Audit on the competitor domain at a later date — some websites relax or update their crawler rules periodically. 4. Focus on auditable competitors. Identify alternative competitors in your niche whose domains are not blocked, and use those audits to inform your strategy instead. ❓ Frequently Asked Questions Is this a Search Atlas bug or limitation? No. CloudFront blocking is a security measure applied by the website owner. Search Atlas has no ability to override or bypass another website's security infrastructure. Can Search Atlas fix this for me? Because the block is enforced by the competitor's server, there is no action our team can take to grant crawler access to a third-party domain. If you are unsure whether the issue is caused by blocking or something else, contact our support team with your project name and the domain you are trying to audit so we can 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.

⏱️ How Long Does a Site Audit Take?

🔍 Overview When you run a Site Audit in Search Atlas, the tool crawls every page of your website to check for technical SEO issues. The time it takes depends on the size and complexity of your site. This article explains what to expect and how to get the most out of the process. ⏳ Typical Audit Durations Most Site Audits complete within the following timeframes: - Small sites (under 500 pages): Usually finishes in a few minutes. - Medium sites (500–5,000 pages): Typically takes 10–30 minutes. - Large sites (5,000+ pages): Can take 30 minutes to several hours depending on server response times and crawl settings. These are estimates. Actual duration may vary based on the factors listed below. ⚙️ What Affects Audit Speed Several factors can make an audit run faster or slower: - Total number of pages: The more pages your site has, the longer the crawl takes. - Server response time: If your server responds slowly to requests, the crawl slows down to match. - Crawl rate settings: A lower crawl rate reduces load on your server but increases audit time. - Redirects and complex URL structures: Sites with many redirects or deeply nested pages take longer to fully map. - JavaScript-heavy pages: Pages that rely heavily on JavaScript to render content may require additional processing time. 📊 How to Check Audit Progress You can monitor your audit in real time directly inside the platform: 1. In the left sidebar, go to Site Metrics → Site Explorer (Site Explorer). 2. Select the property you are auditing. 3. The audit status and progress indicator will be visible at the top of the page. You do not need to keep the page open for the audit to continue — it runs in the background and your results will be ready when you return. 💡 Tips While You Wait There is no need to sit and watch the progress bar. Here are a few productive things you can do while your audit runs: - Review existing keyword data in Keywords → Keyword Magic or Rank Tracker. - Check competitor gaps using Keywords → Keyword Gap. - Plan your next content piece in OTTO SEO → All Sites (SEO Automation) (left sidebar → OTTO SEO → All Sites). 🛠️ What to Do If an Audit Seems Stuck If your audit has been running for significantly longer than the estimates above and shows no progress, try the following steps: 1. Refresh the page to check whether the status has updated. 2. Confirm your site is publicly accessible and not blocking crawlers via robots.txt. 3. Check that your domain is correctly verified and active inside the platform. 4. If the issue persists, cancel the audit and re-run 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.

🔍 Access and Interpret Schema Markup Suggestions

🗺️ What Is the Schema Markup Feature? Schema markup is structured data that helps search engines understand your page content. Search Atlas scans your site and surfaces schema-related suggestions so you can improve how your pages appear in search results. The suggestion count you see reflects the total number of schema opportunities identified across your site. 📍 How to Navigate to Schema Markup 1. Log in to your Search Atlas account. 2. In the header, click the apps grid (More Features). 3. Select Schema Creator to open the Schema Markup section. 4. Click the schema count or the associated link to open the full schema view. 🔢 Understanding the Suggestion Count The number displayed next to Schema Markup means Search Atlas has identified that many individual schema markup opportunities across your site. Each suggestion corresponds to a specific URL or page element where schema could be added, improved, or corrected. - High counts are common on large sites and simply reflect the number of pages or elements flagged — not the severity of any single issue. - The number does not reset automatically — it updates after a new site crawl is completed. - You can page through suggestions using the navigation controls to review each one individually. 👁️ Viewing Detailed Schema Information After clicking into a schema suggestion, you can explore the available details for each flagged URL. The information shown will depend on what Search Atlas detected during the crawl for that page. If the detail view appears limited, the steps below may help: 1. Click directly on the URL or page name listed in the schema suggestion row to open the full per-page view. 2. Review any schema-related data displayed for that page, including what structured data types have been detected and what may be missing or incomplete. 3. If a page shows no detected schema, this means no structured data has been implemented on that page — the suggestion itself is the prompt to add schema. ⚠️ Why Schema Details May Appear Limited There are a few reasons the detail view might seem sparse when you first click into a suggestion: - The page has no existing schema: If a page has not implemented any structured data, the detected schema section will be empty. The suggestion itself is the prompt to add schema — not a reflection of existing code. - The crawl is still processing: If you recently added your site or triggered a new crawl, full schema data may not be populated yet. Wait for the crawl to complete and refresh the page. - Filters are applied: Check whether any active filters are narrowing your view and clear them if needed to see all suggestions. 🛠️ What to Do If You Cannot Find Schema Suggestions If you are having trouble locating or interpreting your schema markup suggestions, try the following steps: 1. Confirm your site has completed at least one full crawl in Search Atlas. 2. Navigate back to the Schema Markup section via the header apps grid (More Features) → Schema Creator, and verify no filters are limiting the results. 3. Refresh the page after a crawl completes to ensure the latest data is displayed. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Check Crawl Status and Understand Crawl Timelines

Overview When you trigger a site crawl in Search Atlas, the process runs in the background so you can continue working. This article explains how to check your crawl status, where to find completed results, and what to expect in terms of timing. Where to Find Your Crawl Status Search Atlas provides a dedicated area within the platform where you can monitor the progress of an active or recently completed crawl. Look for crawl-related options within the site audit or SEO tools section of the left sidebar. Once inside the crawl or audit area, you should see a real-time view of crawl progress, the current state of the crawl, and any errors encountered. Understanding Crawl Status Labels While a crawl is running or after it completes, the platform displays a status indicator. Common states you may encounter include: - Waiting or queued — The crawl has been requested and is waiting to start. This is normal during periods of high demand. - In progress or processing — The crawl is actively running and pages are being discovered and analysed. - Completed or finished — The crawl finished successfully and results are ready to review. - Failed or error — The crawl encountered a problem and did not complete. Triggering a new crawl usually resolves this. If your crawl appears to be running for an unusually long time without progressing, refer to the timing guidance below before taking action. How Long Does a Crawl Take? Crawl duration depends on the size and complexity of your website. Smaller sites will generally complete much faster than larger ones. Factors that can slow a crawl include slow server response times, rate-limiting by the host, large amounts of JavaScript rendering, and a high number of redirects or broken links. If your crawl has been running for several hours without any sign of progress or completion, it is generally safe to cancel it and trigger a fresh crawl from the crawl or audit settings area of the platform. How to Find Results From a Completed Crawl Once a crawl is complete, your results become available within the site audit and page-level reporting sections of the platform. Look for audit findings and individual page data in the relevant areas of the OTTO SEO or site audit tools in the left sidebar. If you started a crawl and cannot locate the results, first confirm that the crawl has fully completed by checking its current status in the crawl monitoring area. If the crawl shows a failed or stuck state, trigger a new scan from the crawl or audit settings area of 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.

🛠️ Site Auditor Add-On Slots Pricing and Purchase

🔍 What Are Site Auditor Add-On Slots? Site Auditor add-on slots allow you to expand the number of websites you can actively audit beyond what is included in your base Search Atlas plan. Each slot represents one additional website you can run full technical SEO audits on, giving you the flexibility to scale your auditing capacity as your client roster or project list grows. 💰 Add-On Slot Pricing Site Auditor add-on slot pricing is charged in addition to your existing plan subscription; the current rate is shown on your Billing page and can vary by plan. There is no minimum number of slots required — you can purchase exactly as many as you need, one at a time. - Cost per slot: varies by plan - check your Billing page for the current rate - Minimum purchase: 1 slot - Billing: Added to your regular monthly or annual billing cycle If you are on an annual plan, add-on slots purchased mid-cycle will be prorated for the remainder of your billing period. 🚀 How to Purchase Additional Site Auditor Slots Follow these steps to add more Site Auditor slots to your account: 1. Log in to your Search Atlas account. 2. Click on your account name or Avatar Menu (👤) in the top-right corner of the platform. 3. Select Billing or Manage Subscription from the dropdown menu. 4. Locate the Site Auditor Add-Ons section on the billing page. 5. Use the quantity selector to choose how many additional slots you want to add. 6. Review the updated cost summary and click Confirm Purchase. Your new slots will be available immediately after purchase. You can then assign them to new websites directly inside the Site Auditor tool. 📊 How to Check Your Current Slot Usage To see how many Site Auditor slots you are currently using versus how many are available on your plan: 1. Navigate to the Site Auditor tool from the left sidebar. 2. Your slot usage is displayed at the top of the Site Auditor dashboard, showing used slots out of your total available slots. If you have reached your slot limit, you will be prompted to purchase additional slots before adding a new website for auditing. 💡 Tips for Managing Your Slots Efficiently - Remove inactive sites: If you are no longer auditing a website, remove it from Site Auditor to free up a slot for a new project. - Plan ahead: If you manage a growing number of clients, consider purchasing a few extra slots in advance to avoid interruptions. - Annual savings: Check whether switching to an annual billing plan offers bundled slot discounts — visit your Billing page for current promotions. 🙋 Need Help with Your Purchase? If you experience any issues during checkout, have questions about your invoice, or need help figuring out how many slots are right for your workflow, we are here to help. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. Additional Notes Specific pricing: $50/month per slot on Starter & Growth plans, $100/month per slot on Pro plan. Also clarifies that subdomains of the same root domain each consume their own slot when set up as independent audit projects.

🔍 Understanding Per-Page Recrawl and Site Metrics

🗺️ Overview When you request a recrawl for a single page in Search Atlas, you may notice that the platform crawls your entire site rather than just the one URL. This article explains why that happens and how to get the most out of your Site Metrics data once the crawl is complete. 🔄 Why Does a Single-Page Recrawl Trigger a Full Site Crawl? Search Atlas crawls your site at the domain level, not on a page-by-page basis. This is by design. Here is why: - Accurate internal linking data: To correctly evaluate any single page, the crawler needs to understand how it connects to the rest of your site. Internal links, anchor text, and crawl depth all influence a page's SEO metrics. - Consistent site-wide metrics: Page authority, crawl health scores, and indexability signals are calculated relative to your full site structure. Crawling only one page would produce incomplete or misleading data. - Dependency on fresh site context: Changes you make to one page — such as updating a title tag or adding a canonical — can affect how other pages are evaluated. A full crawl ensures every metric reflects your site's current state. In short, a "per-page" recrawl request is processed as a trigger to refresh the entire site's crawl data so that all metrics remain accurate and in sync. ⏱️ How Long Will the Crawl Take? Crawl duration can vary depending on your site. Larger or more complex sites may take more time to process. You do not need to stay on the page — your results will be ready when you return. 📊 Viewing Results in Site Metrics Once the crawl is complete, your updated data is available in Site Metrics. Navigate to OTTO SEO → Site Audit → Crawl Monitoring within the platform and select the site you recrawled to review updated crawl health, page-level data, and any flagged issues. If you are unsure where to find your results or your crawl data does not appear to have updated, please reach out to our support team with your project name, the URL you attempted to recrawl, and the approximate time you submitted the recrawl request. If you need further assistance, open 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 Duration and Processing Time Explained

🔍 Overview Running a site audit in Search Atlas is one of the most thorough ways to identify technical SEO issues across your website. Because the audit crawls every page and analyses dozens of data points, it naturally takes some time to complete. This article explains what a normal audit duration looks like and what factors influence processing time. ⏳ How Long Does a Site Audit Take? Audit duration varies depending on the size and complexity of your website. Here are general benchmarks to help set expectations: - Small sites (under 500 pages): Typically 15 minutes to 2 hours - Medium sites (500–5,000 pages): Typically 2 to 5 hours - Large sites (5,000–50,000 pages): Typically 5 to 12 hours - Enterprise sites (50,000+ pages): Can exceed 12 hours in some cases Yes, an 8-hour audit is completely normal for a medium-to-large website. There is no need to cancel or restart the audit if it is still actively processing within these ranges. ⚙️ What Affects Audit Processing Time? Several factors can influence how long your site audit takes to complete: - Total number of pages: The more URLs your site has, the longer the crawl takes. - Server response speed: Slow-loading pages on your website mean the crawler has to wait longer for each response, which extends the overall audit time. - JavaScript-heavy pages: Sites that rely heavily on JavaScript rendering require additional processing time per page. - Crawl rate settings: If you have configured a conservative crawl rate to protect your server, the audit will run more slowly by design. - Platform load: During periods of high demand, audits across the platform may take slightly longer to process. ✅ How to Check Your Audit Status You can monitor the progress of your site audit at any time. Follow these steps: 1. In the left sidebar, click Site Explorer. 2. Select your site from the list to open the audit dashboard. 3. Look for the progress indicator at the top of the audit results page. It will show the percentage of pages crawled so far. 4. As long as the progress percentage is increasing, the audit is running normally — no action is needed. 🚫 When You Should Not Restart the Audit Avoid cancelling or restarting an audit that is still in progress, even if it seems to be taking longer than expected. Restarting will reset all progress and extend the total time needed to complete the audit. Only restart if: - The progress indicator has shown no change for more than 24 hours, or - The audit status displays an explicit error or failed message. 💡 Tips to Speed Up Future Audits If you want to reduce audit times going forward, consider these adjustments: - Exclude unnecessary URLs: Use the crawl settings to exclude parameters, duplicate pages, or non-essential subdirectories that do not need auditing. - Increase the crawl rate: If your server can handle more requests, raising the crawl rate in your audit settings will speed up the crawl. - Schedule audits during off-peak hours: Running audits overnight or during low-traffic periods can improve performance. 🛠️ Still Have Questions? If your audit has been stuck at the same progress percentage for more than 24 hours, or if you see an error message, our team is ready to help. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

JavaScript Rendering in Search Atlas Site Audits: When and How to Use It

Modern websites increasingly rely on JavaScript to render content — from single-page applications (SPAs) to dynamically injected components and client-side personalization. Standard HTML crawlers miss this content entirely, which means audits of JS-heavy sites can produce misleading results. Search Atlas includes an optional JavaScript rendering toggle to ensure crawls reflect exactly what Googlebot sees. What JavaScript Rendering Does When the JavaScript rendering toggle is enabled, Search Atlas's crawler processes: - HTML — the initial document structure - CSS — styling and layout rules that affect content visibility - JavaScript — scripts that inject, modify, or generate content after page load The result is a fully rendered view of each page, including client-side rendered content, dynamically injected elements, and any DOM changes that occur after the initial response. This mirrors how Googlebot evaluates modern web applications. When to Enable JavaScript Rendering JS rendering should only be enabled when it is genuinely needed, because it significantly increases crawl time and resource usage. Common scenarios where it is appropriate: - Single-page applications built with frameworks like React, Vue, or Angular - Sites where critical content is injected after page load - Pages relying on client-side personalization or A/B testing tools - Implementations using pixel-based or script-based content delivery In some cases, Search Atlas will automatically enable JS rendering when it is required — for example, with pixel-based implementations where critical signals only appear after script execution. When You Don't Need JavaScript Rendering Server-side rendered (SSR) environments do not require JavaScript rendering because the content is already present in the initial HTML response. This includes: - Sites using the Search Atlas WordPress plugin - Sites using the Search Atlas Cloudflare integration - Traditional server-rendered CMS platforms For these setups, all changes and optimizations are reflected in the raw HTML, so enabling JS rendering would only add overhead without producing different results. Balancing Accuracy and Performance The JavaScript rendering toggle gives teams flexibility to match crawl behavior to their actual rendering architecture. Use it when accuracy demands it, and leave it off when your stack delivers content in the initial HTML. This ensures audits are both accurate and efficient — without unnecessary performance tradeoffs.

⏱️ Understanding Site Crawl Duration and Speed

🔍 Why Crawl Speed Varies Site crawls in Search Atlas do not run at a fixed speed. Several factors affect how quickly your pages are processed, and it is completely normal for a crawl to take hours — or even longer — depending on your site's conditions. - Site size: Larger sites with hundreds or thousands of pages naturally take more time to crawl than smaller ones. - Server response time: If your web server responds slowly, the crawler waits for each response before moving to the next page. A slow host directly slows down your crawl. - Platform-wide queue: Crawls from all Search Atlas users are processed through a shared queue. During peak usage periods, your crawl may progress more slowly as system resources are distributed across active jobs. - Page complexity: Pages with a large number of internal links, redirects, or heavy JavaScript can take longer to fully process. - Crawl rate limits: To protect your server from overload, the crawler respects rate limits. This prevents large sites from being flooded with rapid requests. 📊 What Is a Normal Crawl Speed? There is no single "normal" speed because every site and server environment is different. As a general guide: - Small sites (under 50 pages) may complete within 15–60 minutes. - Medium sites (50–500 pages) typically take a few hours. - Larger sites (500+ pages) can take several hours to over a day. Seeing only 24 out of 110 pages crawled after several hours is within the range of expected behaviour, particularly if your server has slower response times or the platform queue is busy. The crawl is still running — it has not stalled. ⚙️ How to Check Your Crawl Progress You can monitor an active crawl directly inside Search Atlas: 1. In the left sidebar, click Site Metrics (Site Explorer). 2. Select your site from the list at /site-explorer/list. 3. Review the crawl status indicator to see how many pages have been processed and whether the crawl is still active. As long as the crawl status shows as in progress, the job is running normally. Refreshing the page periodically will update the page count. 💡 Tips to Help Your Crawl Complete Faster While you cannot directly control platform queue times, there are steps you can take to reduce delays caused by your own site: - Improve server response time: Use caching, a CDN, or speak to your hosting provider about performance optimisation. Faster server responses mean faster crawls. - Fix redirect chains: Multiple redirects on a single URL slow down the crawler. Resolve any unnecessary redirect chains in advance. - Avoid triggering a re-crawl unnecessarily: Starting a new crawl before a previous one finishes can reset your progress. Wait for the current crawl to complete first. - Crawl during off-peak hours: Scheduling crawls overnight or during low-traffic periods on your site can sometimes result in faster completion. 🚨 When Should You Be Concerned? In most cases, a slow crawl is not a problem — it just requires patience. However, you should reach out for support if: - The crawl status has shown no progress at all for more than 24 hours. - The crawl appears to be stuck on the same page count over an extended period without any movement. - You receive an explicit error message or the crawl shows a failed status. If you are unsure whether your crawl is progressing normally, it is always fine to check in with our team. 🛠️ Need Further Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Find and Fix Crawl Issues in Site Auditor

🗺️ Overview Site Auditor scans your website and flags technical issues — including broken links (404 errors) — that can hurt your search rankings. This article explains how to locate crawl issues and 404 errors inside Site Auditor and what you can do to resolve them. 🧭 How to Navigate to Site Auditor Follow these steps to open Site Auditor from any page in Search Atlas: 1. Log in to your Search Atlas account. 2. Look at the left sidebar and click OTTO SEO, then select Site Audit (Site Auditor) from the nested menu. 3. If you have more than one project, select the correct website for the project you want to audit. 4. Wait for the dashboard to load. If a crawl has already been run, your results will appear immediately. If this is your first visit, initiate a new crawl using the option available on the dashboard. Note: A crawl may take a few minutes to complete depending on the size of your website. Wait for the crawl to finish before reviewing results. 📋 How to Find Crawl Issues Once the crawl is complete, your results are displayed on the Site Auditor dashboard. Here is how to locate your issues: 1. On the main Site Auditor dashboard, look for the section that lists detected problems. This is where every crawl issue is reported after scanning completes. 2. Browse through the issues list to surface 404 or broken link errors specific to your site. 3. Click on any issue to expand it and see further details about the affected URLs. Tip: If you see no issues listed but expect problems, check whether the crawl finished successfully. If the crawl is still running, wait for it to complete and then refresh the page. 🔗 How to View 404 Broken Link Details Once you have located 404 errors in the dashboard, Site Auditor provides additional information to help you understand the scope of the problem: - Broken destination URL: The page that returned a 404 error. - Referring page: The page on your site that contains the broken link. Reviewing these details tells you exactly which pages you need to edit in order to resolve each error. 🛠️ How to Fix 404 Errors There are two main ways to fix a broken link, depending on whether the destination page exists or not: 1. If the destination page has moved: Set up a 301 redirect from the old URL to the new one. This preserves link equity and automatically sends visitors to the correct page. 2. If the destination page no longer exists: Edit the linking page and remove or update the broken link so it points to a valid, relevant URL instead. After making your fixes, return to Site Auditor and run a new crawl to confirm the 404 errors have been resolved. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⏳ Understanding Website Engagement and Crawl Timelines

🔍 What Does 'Website Engagement' Mean? When you connect a website to OTTO SEO and complete the initial configuration, Search Atlas begins an engagement process. This means OTTO SEO is actively analysing your site, running a full audit crawl, and preparing personalised optimisation recommendations. Until this process completes, your website will show as not yet engaged — this is completely normal. ⏱️ How Long Does Engagement Take? The engagement and crawl timeline depends on the size and complexity of each website. Here is what you can generally expect: - Small websites (under 100 pages): Typically 30 minutes to 2 hours. - Medium websites (100–1,000 pages): Typically 2 to 12 hours. - Large websites (1,000+ pages): Can take up to 24–48 hours in some cases. If you have configured two websites at the same time, each site goes through its own independent crawl queue. Both sites may take time to become fully engaged, and one may complete before the other — this is expected behaviour. 🛠️ What Happens During the Crawling Process? Once you complete configuration, OTTO SEO performs the following steps automatically: 1. Site discovery: OTTO SEO maps all accessible pages on your website by following internal links and your sitemap. 2. Technical audit: Each page is scanned for SEO issues such as broken links, missing metadata, slow load times, and crawlability problems. 3. Data processing: Crawl results are analysed and matched against your target keywords and SEO goals. 4. Engagement activation: Once processing is complete, your site status updates to Engaged and recommendations become available. ✅ How to Check Your Engagement Status You can monitor the status of your websites at any time by following these steps: 1. In the left sidebar, click OTTO SEO V3. 2. Your connected websites will be listed on the dashboard. Each site displays its current engagement status. 3. If a site is still processing, you will see a pending or loading indicator next to it. 4. Once engagement is complete, the status will update automatically — no page refresh is required. You do not need to re-run configuration or reconnect your site. Simply allow the crawl to finish. 💡 Tips While You Wait - Make sure your website is publicly accessible and not blocked by a robots.txt rule or password protection, as this can prevent the crawler from completing. - Confirm that your sitemap URL was entered correctly during configuration, as a missing or incorrect sitemap can slow down the discovery phase. - Avoid making large structural changes to your website while the initial crawl is in progress, as this can affect the accuracy of the audit results. - If you have multiple sites queued, the one added first will generally be crawled first. ⚠️ When to Reach Out for Help In most cases, engagement completes within the timeframes listed above. However, you should contact support if: - Your website has been showing not engaged for more than 48 hours after completing configuration. - You see an error message on the OTTO SEO V3 dashboard instead of a progress indicator. - Only one of your two websites engaged successfully and the other has shown no progress for over 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.

💰 Site Audit Add-On Pricing and Purchase Guide

🔍 Overview Every Search Atlas plan includes Site Audit access with a monthly crawl allowance that varies by plan. If you need more Site Audit capacity than your plan includes, Search Atlas offers a paid Site Auditor add-on. This article explains the add-on pricing and walks you through how to add it to your account. 📊 Site Auditor Add-On Pricing The Site Auditor add-on is priced as follows: - Starter and Growth plans: $50/month - Pro plan: $100/month - Billing: Add-on charges are added to your regular monthly bill For the exact crawl/page allowance included with the add-on on your specific plan, check your account's Top-right corner (avatar) → Billing → Plans & Top-ups tab — allowances can be updated over time. 🛠️ How to Purchase Additional Site Audit Projects Follow these steps to add more Site Audit projects to your account: 1. Log in to your Search Atlas account. 2. Navigate to your Account Settings or Billing section. 3. Locate the Site Auditor add-on option. 4. Review the monthly cost for your plan tier ($50/month on Starter/Growth, $100/month on Pro) and confirm your purchase. Your additional Site Audit capacity will be available immediately after purchase, and the cost will appear on your next invoice. 💡 Tips for Managing Your Site Audit Usage - Audit only active sites: Remove projects for domains you no longer manage to stay within your allowance and avoid unnecessary charges. - Plan ahead: If you regularly onboard new clients, consider how many audits you typically run per month so you can budget accordingly. - Review usage regularly: Check your active Site Audit projects periodically to ensure you are not paying for capacity you do not need. ❓ Frequently Asked Questions Can I remove the add-on later? Yes. You can cancel the Site Auditor add-on at any time through your billing settings. Changes will take effect at the start of your next billing cycle. Does the price differ by plan? Yes. The Site Auditor add-on is $50/month on the Starter and Growth plans, and $100/month on the Pro plan. 🆘 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.

🔍 Understanding Inlinking Pages in Onpage Audit

🧭 What Is the Onpage Audit? The Onpage Audit in Search Atlas analyzes individual pages on your website and surfaces technical and content-related issues that may be holding back your search rankings. One of the data points it reports on is Inlinking Pages. 🔗 What Are Inlinking Pages? Inlinking Pages refers to the number of other pages on your own website that contain a hyperlink pointing to the page being audited. These are also commonly called internal links or internal backlinks. For example, if your homepage, your blog index, and a product page all contain a link that points to a specific article, that article has 3 Inlinking Pages. This metric is strictly about internal links — links from other pages within the same domain. It does not count links from external websites. 📊 Why Do Inlinking Pages Matter for SEO? The number of inlinking pages is a strong signal of how well a page is connected within your website's architecture. Here is why it matters: - Link equity distribution: Pages that receive more internal links accumulate more authority, which can help them rank higher in search results. - Crawlability: Search engine bots follow internal links to discover and index your content. Pages with zero or very few inlinking pages are harder for bots to find and may be crawled less frequently. - User navigation: Internal links guide visitors to related content, improving engagement and time on site. - Orphaned pages: A page with 0 inlinking pages is considered an orphan page. Orphan pages are at serious risk of being missed by crawlers and receiving no organic traffic. 📋 How to Find Inlinking Pages Data in Search Atlas 1. Log in to your Search Atlas account. 2. Navigate to the Onpage Audit section within your project. 3. Select the page you want to review. 4. Locate the Inlinking Pages value shown for that page — this number shows how many internal pages link to the audited URL. 🛠️ How to Improve Your Inlinking Pages Score If a page has a low inlinking count — or none at all — take the following steps to strengthen its internal link profile: - Add contextual links: Edit related blog posts, guides, or service pages and add a natural, relevant hyperlink pointing to the target page. - Update your navigation: If a page is important, consider adding it to your main menu, footer, or sidebar so it receives links from every page on the site. - Create supporting content: Write new articles or landing pages that naturally reference and link to the target page. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🗑️ Delete a Duplicate Site Explorer Project

🔍 Overview If you created two OTTO Site Explorer projects for the same website — for example, one targeting the US and one targeting the UK — and you no longer need one of them, you can delete the duplicate from the Site Explorer area. This article explains what to expect when removing a duplicate OTTO Site Explorer project by region. Important: OTTO Site Explorer projects are managed under Site Metrics (Site Explorer) in the left sidebar. This is a separate area from Website Studio (also called Web Studio). If you are trying to delete a Website Studio project, please refer to the relevant article for that product. 📋 Before You Delete Keep the following in mind before removing a project: - Deleting a project is permanent. All historical data, tracked metrics, and configurations associated with that project will be removed and cannot be recovered. - Make sure you are deleting the correct regional version. Double-check the target country or region assigned to the project before proceeding. - Only delete the project you no longer need — in this example, the US version — and confirm the project you want to keep (the UK version) is still active and correctly configured. 🧭 How to Find Your OTTO Site Explorer Projects 1. Log in to your Search Atlas account. 2. In the left sidebar, click Site Metrics (Site Explorer). 3. You will land on the project list page, which displays all your OTTO Site Explorer projects. 4. Locate the two projects for the same website. You can identify the regional difference by the country or region label shown on each project card. 🗑️ How to Delete the Duplicate Project 1. On the Site Explorer project list page, find the OTTO Site Explorer project you want to remove (for example, the US version). 2. Look for the delete or remove option available on the project entry. 3. Select the option to delete the project and follow any on-screen prompts to confirm your choice. 4. Once completed, the deleted project will no longer appear in your project list. Your remaining project — in this example, the UK version — will be unaffected and will continue to retain all its data and settings. Note: If you are unsure how to locate the delete option for your OTTO Site Explorer project, or if the option does not appear as expected, please reach out to the support team for guidance specific to your account. ✅ Confirming the Right Project Remains After deletion, take a moment to verify everything looks correct: - Return to Site Metrics (Site Explorer) in the left sidebar. - Confirm only one project for your website is listed. - Click into the remaining project and check that the target region (for example, United Kingdom) is correctly set. - Review any active tracking — such as rank tracking or keyword data — to confirm it is intact. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⚡ Navigate Site Audits, Promo Codes, and Saved Projects

Overview This article covers three common account questions: how to find your site audits, how to apply a promo code to your subscription, and why you may see saved projects you don't remember creating. How to Navigate to Your Site Audits List Your site audits are stored within the Search Atlas platform. To locate your audits, log in to your account and navigate to the Site Audit section of the platform. From there you can view previously run audits and open any audit to review its results. If you have run an audit but do not see it listed, try the following: - Confirm you are logged in to the correct account — audits are saved per account, not per browser session. - Check whether the audit was run under a different project or domain by reviewing all projects listed in your dashboard. - If the audit still cannot be found, contact support with your account email address, the site URL you audited, and the approximate date the audit was run. How to Apply a Promo Code You can apply a promo or discount code to your subscription through your billing settings. To do so, log in to your Search Atlas account and navigate to your Avatar (top-right) → Billing → Redeem Promo Code. Locate the option to enter a coupon or promo code, enter your code exactly as provided — including any uppercase or lowercase letters — with no extra spaces before or after the code, then submit it to have the discount applied. If the code does not apply successfully, check the following before contacting support: - Confirm the code has not expired. - Ensure you are entering the code on the correct account (the account the code was issued to). - Check that you have not already applied a different discount to this subscription. If you have tried the steps above and the code still does not work, our support team can verify the code and assist with applying it. When reaching out, please have the following ready: - Your exact promo code - Your account email address - A description of any error message you received Understanding Saved Projects You Did Not Create It is possible to find saved projects in your account that you do not recall setting up. The most common reason is that another user on a shared account created those projects. If you are unsure of the origin of a saved project, review which team members have access to your account and check with them before deleting anything. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔄 Trigger a Site Auditor Recrawl After Restructuring

🗺️ Why a Recrawl Is Needed After Architecture Changes When you make significant changes to your website — such as restructuring your hub-and-spoke architecture, reorganising URL hierarchies, adding new content hubs, or updating internal linking — the Site Auditor retains data from its most recent crawl. Until a new crawl runs, the audit results will reflect your old site structure, not the updated one. Triggering a fresh recrawl tells the system to re-examine every accessible page on your domain and rebuild its understanding of your site's current architecture, links, and technical health. 🛠️ How to Trigger a Recrawl in Site Auditor Follow these steps to start a new crawl for your project: 1. Log in to your Search Atlas account and navigate to Site Auditor from the left-hand menu. 2. Select the project (domain) you want to recrawl from your project list. 3. Once inside the project dashboard, locate the option to initiate a new crawl and confirm the action when prompted. The crawl will begin and may take several minutes to complete depending on the size of your site. 4. Once finished, your audit results will refresh to reflect your updated site structure, internal links, and technical health data. 💡 Best Practices When Recrawling After Major Changes - Wait until changes are fully live. Run the recrawl only after all your architecture updates have been published and are accessible to crawlers. Recrawling a half-deployed site will produce mixed results. - Submit an updated sitemap first. Before triggering the recrawl, submit your refreshed XML sitemap to Google Search Console. This ensures both Google and Site Auditor are working from the same URL set. - Check your robots.txt. Confirm that no sections of your new architecture are accidentally blocked from crawling before you initiate the 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.

🔌 Pixel Status During Site Audit Installation

🧭 Overview After installing the Search Atlas pixel on your website, you may notice that its status appears as Disconnected inside the platform. This is expected behaviour during the initial site audit crawling phase and does not mean something has gone wrong. This article explains why this happens and what you should do. 🤔 Why Does the Pixel Show as Disconnected? When you first install the pixel, Search Atlas needs to crawl your website before it can verify that the pixel is live and firing correctly. During this crawling process, the platform has not yet confirmed the pixel's presence on your pages, so the status is temporarily displayed as Disconnected. This is a normal part of the setup sequence. The disconnected status does not mean the pixel was installed incorrectly — it simply means verification is still in progress. ⏱️ How Long Does Verification Take? Pixel verification is completed once the initial site audit crawl finishes. The timeline depends on the size of your website. You do not need to reinstall the pixel or take any action during this window. The status will update automatically once the crawl is complete. ✅ How to Confirm Your Pixel Is Installed Correctly Before waiting for the crawl to finish, it is worth doing a quick check to make sure the pixel code is in place. Follow these steps: 1. Log in to Search Atlas and navigate to the Site Audit section of the platform. 2. Locate your pixel installation code inside the platform and copy it. 3. Open your website and inspect the page source (right-click the page and select View Page Source). 4. Use your browser's search function (Ctrl+F or Cmd+F) to search for the pixel ID or a unique portion of the pixel script. 5. Confirm the pixel code appears in the <head> section of your page. If you find the pixel code in your page source, the installation is correct and you can simply wait for the crawl to complete. 🔄 What to Do If the Pixel Remains Disconnected If the pixel status still shows as Disconnected after the initial crawl has had time to complete, contact our support team for assistance. When reaching out, please have the following ready: - Your project or property name as it appears in Search Atlas - The date and time you installed the pixel - Confirmation of whether the pixel code appears in your page source If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🗺️ Finding Your Sitemap Link to Submit to Google Search Console

Your sitemap link lives in a different place depending on which Search Atlas product manages your website. Find your product below to get the exact link to submit to Google Search Console. 📝 If Your Site Uses MetaSync (WordPress Plugin) 1. Log in to your WordPress admin dashboard. 2. Go to MetaSync → XML Sitemap. 3. The Sitemap Status card shows your Sitemap Index URL as a clickable link. Your sitemap link will look like: https://yourdomain.com/sitemap_index.xml 🖥️ If Your Site Was Built with Website Builder (Landing Page Studio) 1. Open your project in the Website Builder. 2. Go to the SEO Files panel. 3. Click View live file next to sitemap.xml. Your sitemap link will look like: https://yourdomain.com/sitemap.xml 📤 Submitting Your Sitemap to Google Search Console 1. Log in to Google Search Console. 2. Select your property. 3. Go to Sitemaps in the left menu. 4. Paste your sitemap link from above and click Submit. 💬 Not Sure Which Product Manages Your Site? If you're not sure whether your site is managed through MetaSync or Website Builder, or you don't see either option, open 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 Audits on Trial Accounts Explained

🧭 Overview If you are evaluating Search Atlas on a trial account, you can still run site audits for prospective clients using a dedicated lookup tool that does not consume one of your project slots, making it ideal for agency prospecting and pre-sales research. 📍 What Is the Difference Between Ongoing Projects and On-Demand Site Research? Search Atlas separates ongoing project tracking from on-demand site research: - Projects are created when you want to continuously monitor a specific website — tracking rankings, auditing on a schedule, and managing SEO tasks over time. Each project occupies one of your available project slots. - On-demand site research tools let you pull data for any domain at any time without creating a project and without using a project slot. This is the right approach to audit a prospective client's site quickly during a trial. 🗂️ How to Run a Site Audit Without Using a Project Slot 1. Log in to your Search Atlas account. 2. Navigate to the appropriate on-demand research or site analysis area within the platform. 3. Enter the domain of the prospective client you want to audit. 4. Generate the report and review the available site data for that domain. You can repeat this process for as many prospective client domains as you need during your trial. 🎬 Finding Tutorial Videos and Getting-Started Resources If you want to learn more about how to use Search Atlas features during your trial, the most reliable way to find tutorial resources is to reach out directly through the platform's support chat. A team member can point you to the right videos and guides for the specific tools you want to explore. You can also browse any in-platform help options available within your account for contextual guidance on the page you are currently viewing. If you need further assistance, open 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 Recrawled Sites Take Time to Appear in Active Projects

🔍 Overview After triggering a recrawl for a site, you may notice that it does not immediately appear — or reappear — under the Active tab in OTTO SEO → All Sites (SEO Automation). This is expected behavior. Search Atlas requires some time to fully process a recrawl and reflect the updated site data in your Active Projects list. This article explains why the delay happens and what to expect while the process completes. ⚙️ Why the Delay Happens When you trigger a recrawl, Search Atlas begins collecting and indexing fresh data from your site. Until this background processing is complete, the site will not appear in the Active tab under OTTO SEO → All Sites (SEO Automation). The time required can vary depending on your site's size and complexity. ✅ What to Do While You Wait There are a few things to keep in mind while the recrawl is being processed: - The delay is tied to backend data processing, not a display issue. Refreshing the page or logging out and back in will not speed up the process. - Check back after giving the process adequate time to complete. The site should appear in the Active tab under OTTO SEO → All Sites (SEO Automation) once processing finishes. - If the site still has not appeared after an extended wait, note the exact site URL and the approximate time you triggered the recrawl, as this information will help our team investigate. 🛠️ When to Contact Support If your recrawled site has not appeared in the Active tab under OTTO SEO → All Sites (SEO Automation) after an extended wait, please reach out to our support team. To help us investigate as quickly as possible, have the following ready: - The exact site URL you recrawled - The approximate date and time you triggered the recrawl - A description of what you currently see in OTTO SEO → All Sites (SEO Automation) If you need further assistance, open 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 Nameserver Downtime

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

🔍 Site Auditor Add-On Slots: Pricing and Purchase Guide

🧩 What Are Site Auditor Add-On Slots? Site Auditor slots determine how many websites you can actively audit within your Search Atlas account. Every plan includes a base number of slots. If you need to audit more sites than your plan allows, you can purchase additional slots as an add-on without upgrading your entire plan. 💰 Add-On Slot Pricing Site Auditor add-on slot pricing depends on your base plan: $50 per slot per month on Starter and Growth plans, and $100 per slot per month on the Pro plan. Each additional slot lets you add one more website to your active audit queue. You can purchase as many extra slots as your workflow requires, and the cost is billed on the same monthly cycle as your main subscription. - Price per slot: $50/month (Starter & Growth) or $100/month (Pro) - Billing: Monthly, aligned with your existing subscription renewal date - Minimum purchase: 1 slot - Maximum purchase: No hard cap — add as many as you need 📋 What Counts as a Slot? Each slot corresponds to one root domain or subdomain that you configure for auditing. For example, if you want to audit three separate client websites and your plan includes only one slot, you would need to purchase two additional slots. Subdomains of the same root domain each consume their own slot when set up as independent audit projects. 🛒 How to Purchase Additional Slots 1. Log in to your Search Atlas account. 2. Click your account name or avatar in the top-right corner of the platform. 3. Select Billing or Manage Subscription from the dropdown menu. 4. Scroll to the Add-Ons section of your subscription page. 5. Locate Site Auditor Slots and click Add Slots. 6. Enter the number of additional slots you want to purchase. 7. Review the prorated charge for the current billing cycle, then confirm your purchase. Your new slots are activated immediately after payment is confirmed. You can then add new websites to your Site Auditor right away. ⚡ How to Start Auditing a New Site After Purchasing 1. In the left sidebar, navigate to OTTO SEO. 2. Select Site Audit to open the Site Audit page. 3. Click the Audit Site button. 4. Enter the website URL you want to audit and configure your preferred crawl settings. 5. Click Recrawl Site to begin crawling the site. 📊 Checking Your Current Slot Usage You can view how many Site Auditor slots your plan includes and how many you have used at any time. Go to Top-right corner (avatar) → Billing → Plans & Top-ups tab and look for the Site Auditor row under your plan details. The used and available slot counts are displayed there. This helps you plan ahead before onboarding new clients or domains. ❓ Frequently Asked Questions - Can I remove add-on slots if I no longer need them? Yes. You can reduce your add-on slot count at any time from the Top-right corner (avatar) → Billing → Plans & Top-ups tab. Changes take effect at the start of your next billing cycle, and you will not be charged for removed slots going forward. - What happens to audited sites if I remove a slot? If you reduce your slot count below your active projects, you will be prompted to archive or remove a project before the change is finalised. Archived project data is retained for 90 days. - Are annual plan discounts available for add-on slots? At this time, add-on slots are billed monthly only, regardless of whether your base plan is on an annual cycle. - Is there a free trial for extra slots? Add-on slots do not include a separate free trial period, but you can cancel them at the end of any billing month. 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Find SEO Issues and Affected Pages in OTTO

🗺️ Overview OTTO SEO includes a built-in Site Audit tool that scans your website and surfaces SEO issues grouped by type. This article walks you through how to navigate to the audit, locate affected pages, and understand the information available so you can start fixing issues quickly. 🚀 Step 1: Open OTTO SEO 1. Log in to your Search Atlas account. 2. In the left sidebar, click OTTO SEO, then SEO Automation. This takes you to the main OTTO SEO dashboard (All Sites) at /seo-automation-v3. 3. You will see a list of your connected sites under the All Sites view. Active and Deep Frozen sites are shown here. 🌐 Step 2: Select Your Website 1. From the All Sites list, click the website you want to audit. 2. This opens the Overview page for that site, where you can see a high-level summary of your site's SEO health. 3. If you have not yet run a scan, click the Scan button at the top of the Overview page to trigger a fresh crawl of your site. 📋 Step 3: Navigate to All Audits 1. In the left sidebar, click OTTO SEO, then Site Audit, then select All Audits. 2. This page lists every audit that has been run for your connected sites, along with the scan date and a summary of issues found. 3. Click on a specific audit to open the full audit report for that scan. 🔎 Step 4: Browse Issues and Find Affected Pages Inside the audit report, issues are organised by category — for example, missing meta titles, broken links, slow page speed, and more. Here is how to drill down to the affected pages: 1. Scroll through the Issues section to see all detected SEO problems, each showing a count of how many pages are affected. 2. Click on any issue to expand it and reveal the list of specific pages that have that problem. 3. Use the View Pages option within an issue to see the full list of affected URLs, along with relevant details such as the current value and the recommended fix. 4. You can sort or filter the list to prioritise the pages that will have the greatest impact on your SEO performance. 📊 Step 5: Use Crawl Monitoring for Ongoing Tracking In addition to on-demand audits, OTTO SEO includes Crawl Monitoring for continuous tracking of your site's health. - Go to Left sidebar → OTTO SEO → Site Audit → Crawl Monitoring to view live crawl data and track newly discovered issues over time. - This is especially useful for large sites where new pages are published frequently or where issues may appear after a site update. 💡 Tips for Getting the Most from Site Audit - Run a fresh scan after making changes to your site so the audit reflects your latest content. - Start with high-impact issues — issues affecting the most pages or flagged as critical will typically deliver the biggest SEO gains when fixed. - Check the Knowledge Base inside OTTO SEO (Left sidebar → OTTO SEO → Knowledge Base) for guidance on how to resolve specific issue types. - Use the Overview page as your starting point each session — it gives a quick summary of your site's overall health score and highlights areas needing attention. 🛠️ Troubleshooting - Audit not loading or showing an error: Refresh the page and try again. If the issue persists, run a new scan from the Overview page. - Page count looks incorrect: This can happen immediately after a new scan finishes. Wait a moment and refresh the audit report to see updated counts. - No issues showing: Confirm that OTTO SEO is properly installed on your site by visiting Left sidebar → OTTO SEO → Installation Guide. 💬 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.

📋 Interpret and Use the Site Audit Pruning Report

🔍 What Is the Pruning Report? The Pruning Report is a section inside Site Audit that lists every page on your site alongside the SEO issues detected on it. Its purpose is to help you decide which pages are worth keeping, improving, or removing from your site entirely. Each page in the report is evaluated against a set of SEO criteria. A page is counted as healthy only when all detected issues on that page have been either resolved or deliberately marked as ignored. Until that happens, the page remains in an unresolved state and does not contribute to your healthy pages score. 📊 Why Your Healthy Pages Score Shows Zero The healthy pages metric reflects the percentage of crawled pages that have no outstanding issues. If your score is sitting at zero — or very close to it — one of the following is usually the cause: - All crawled pages have at least one unresolved issue. Even a single low-priority issue on every page is enough to keep the score at zero. - The crawl has only just completed. Scores are calculated after the crawl finishes processing. Give the platform a few minutes to update the dashboard after a fresh crawl. - No issues have been reviewed yet. The pruning report requires you to take action — resolve or ignore — before pages are marked healthy. A zero score does not automatically mean your site has severe technical problems. It most commonly means the review workflow has not been started yet. ✅ How Resolving or Ignoring Issues Affects Your Score Every page moves through a simple lifecycle inside the pruning report: 1. Crawled — the page has been discovered and scanned. 2. Issues detected — one or more SEO problems are flagged on the page. 3. Reviewed — you either fix the issue on your site and mark it resolved, or you decide the issue does not apply and mark it ignored. 4. Healthy — once every issue on a page is either resolved or ignored, the page is counted as healthy and your score improves. This means ignoring an issue is a completely valid action and counts toward your score just as much as fixing it. Ignoring does not hide a real problem — it tells the platform that you have reviewed the issue and made a conscious decision that it does not need to be addressed. ⚖️ When to Resolve vs. When to Ignore an Issue Use the guidance below to decide the right action for each flagged issue: - Resolve the issue when it is a genuine problem that could harm rankings, user experience, or crawlability — for example, a broken internal link, a missing meta description on an important landing page, or a page with duplicate title tags. - Ignore the issue when it does not apply to your site's context — for example, a "thin content" warning on a deliberately short utility page, a missing canonical on a page you intentionally left without one, or a redirect flag on a page that is correctly redirecting. - Ignore in bulk when the same issue type appears across many pages that share the same intentional structure — for instance, paginated archive pages or tag pages that are expected to have limited unique content. When in doubt, prioritise resolving issues on your highest-traffic and highest-priority pages first, then use ignore to clear lower-priority flags across the rest of your site. 🗂️ Recommended Workflow When Issue Counts Are High If your crawl has surfaced a large number of issues, working through them systematically will move your healthy pages score in the right direction without feeling overwhelming. 1. Filter by issue severity. Start with critical and high-severity issues. These have the most impact on rankings and user experience and should be resolved before moving to warnings or notices. 2. Group by issue type. Fixing one issue type across all affected pages at once is faster than reviewing page by page. For example, address all missing H1 tags in one pass before moving to the next issue category. 3. Bulk-ignore low-priority issue types. After reviewing a category, if the issues are not relevant to your site, use the bulk ignore option to clear them all at once and immediately raise your healthy pages count. 4. Re-crawl after making fixes. Once you have made technical changes on your site, trigger a new crawl so the platform can verify the issues are resolved and update the healthy pages score accordingly. 5. Review the pruning report regularly. Aim to keep the number of unreviewed pages low. A consistent review habit prevents the score from drifting back to zero after future crawls. 💡 Quick Tips - Your healthy pages score will not update in real time as you click resolve or ignore — allow a short processing window after taking bulk actions. - Pages added since the last crawl will not appear until you run a new crawl. - Ignoring an issue only affects the platform's reporting — it does not change anything on your live website. 🆘 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix OTTO Footer 404 External Links Fast

🔍 What Are OTTO Footer Backlinks? When OTTO is activated on your site, it may inject a small otto-community-backlink div in your site's footer. This div contains external links that are part of the OTTO community backlink network. Over time, some of these external URLs can return a 404 (Not Found) status, meaning the destination page no longer exists. OTTO automatically monitors these footer links for you, but it is important to understand where to find them, how to identify broken ones, and what steps to take when a 404 is detected. 📍 Where to Find OTTO Footer Link Monitoring 1. Log in to your Search Atlas account. 2. In the left sidebar, click OTTO SEO, then open SEO Automation (URL: /seo-automation-v3). 3. Select the project or domain you want to review. 4. Navigate to the OTTO Dashboard for that project. 5. Look for the External Links or Backlink Health section within the OTTO interface — this is where footer link statuses are reported. OTTO continuously checks the status of every external link it has placed in your site's footer. Any link returning a 404 error will be flagged automatically in this section for your review. ⚠️ Why 404 Footer Links Are a Problem Broken outbound links in your footer can negatively affect your site in several ways: - User experience: Visitors who click a broken link encounter an error page, reducing trust in your site. - Crawl budget: Search engine bots waste crawl budget following dead-end links. - SEO signals: Too many broken outbound links can weaken your site's perceived quality in search engine assessments. Resolving these 404 links promptly keeps your site healthy and your OTTO network participation in good standing. 🛠️ How to Fix OTTO Footer 404 Links Once you have identified broken footer links inside the OTTO Dashboard, follow these steps to resolve them: 1. Review the flagged links: In the External Links or Backlink Health section, you will see a list of footer URLs with their current HTTP status. Focus on any link marked 404. 2. Let OTTO auto-replace the link: In most cases, OTTO will automatically queue a replacement URL from the community network to swap out the broken link. Check whether an auto-replacement is already pending for the flagged link — if it is, no manual action is needed. 3. Manually remove or deactivate the link: If auto-replacement is not available or you prefer manual control, use the toggle or remove option next to the broken link inside the OTTO Dashboard to deactivate it. This removes the broken URL from your footer's otto-community-backlink div immediately. 4. Re-run an OTTO scan: After making changes, trigger a fresh scan from the OTTO Dashboard to confirm the 404 link no longer appears in your footer and that all remaining footer links return healthy status codes. 5. Verify on your live site: Inspect your site's footer directly — either via your browser's developer tools or a source-code view — to confirm the otto-community-backlink div no longer contains the broken URL. 🔄 How OTTO's Automatic Monitoring Works OTTO runs scheduled health checks on every external link it manages in your footer. Here is what happens automatically: - Continuous scanning: OTTO periodically sends requests to each footer link URL to verify it returns a valid 200 status code. - 404 flagging: Any URL that returns a 404 response is immediately flagged in your OTTO Dashboard with the affected link and its status. - Auto-replacement queue: When a replacement URL is available in the community network, OTTO queues it to replace the broken link without requiring manual intervention. - Dashboard alerts: You will see a notification or count update in your OTTO SEO V3 dashboard whenever new broken footer links are detected, so you are never left unaware. Because monitoring is automatic, you do not need to manually check your footer's HTML on a recurring basis — OTTO surfaces the issues for you inside the platform. 💡 Best Practices for Healthy Footer Links - Check your OTTO Dashboard at least once a week for any newly flagged 404 links. - Do not manually edit or delete the otto-community-backlink div from your site's theme or template — always manage these links through the OTTO Dashboard to avoid sync issues. - If you notice a spike in 404 detections, trigger a manual re-scan to ensure OTTO's data is up to date. - Keep OTTO activated and your project connected so monitoring remains active at all times. 🆘 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.

🔍 Identifying Search Atlas Dynamic Optimization Code Snippet

🧩 Overview If you notice an unfamiliar script on your website and want to know whether it belongs to Search Atlas, this article explains exactly what to look for. The Search Atlas dynamic optimization snippet has specific, identifiable markers that make it easy to confirm at a glance — no login or account details required. 🔎 Key Identifiers of the Search Atlas Snippet The Search Atlas dynamic optimization script contains three reliable signatures. If all three are present, the code belongs to Search Atlas. - Element ID: The script tag includes the attribute id='sa-dynamic-optimization'. This unique ID is only assigned by Search Atlas and will not appear in third-party scripts. - Domain reference: The snippet loads resources from or communicates with the domain dashboard.atlascoremarketing.com. Look for this domain in the src attribute or within the script body. - Base64-encoded loader pattern: The snippet uses a base64-encoded string to load its core script. You will see a long string of characters using only letters, numbers, +, /, and = padding — this is the encoded loader. It is typically assigned to a variable or passed directly into a script initialisation call. 📋 How to Locate the Snippet on Your Website 1. Open your website in a browser and right-click anywhere on the page, then select View Page Source or Inspect. 2. Press Ctrl + F (Windows) or Cmd + F (Mac) to open the search bar within the source view. 3. Search for sa-dynamic-optimization. If the snippet is present, this term will highlight immediately. 4. Confirm the surrounding code also references dashboard.atlascoremarketing.com and contains a base64-encoded string as described above. 5. If all three identifiers are present, the script belongs to Search Atlas dynamic optimization. ✅ Quick Reference: What the Snippet Looks Like Below is a summary of the three markers to check side by side: - **id attribute:**id='sa-dynamic-optimization' - **Domain:**dashboard.atlascoremarketing.com - Loader format: A base64-encoded string (long alphanumeric sequence ending in one or two = characters) You only need to find one of these to begin your investigation, but all three will be present in a legitimate Search Atlas snippet. If any identifier is missing or the domain is different, the script may belong to another service. ⚠️ What If the Script Does Not Match These Identifiers? If the script on your site does not include id='sa-dynamic-optimization', does not reference dashboard.atlascoremarketing.com, and does not contain a base64-encoded loader, it is not a Search Atlas dynamic optimization snippet. In that case, check with your developer or review your tag manager to identify the service that injected it. 🗑️ Removing or Managing the Snippet If you have confirmed the snippet belongs to Search Atlas and wish to manage or remove it, the setting is controlled from within your Search Atlas dashboard. Changes to dynamic optimization are applied at the account level and will reflect on your site after the next page load. If you are unsure which setting controls the snippet, your developer or the Search Atlas support team can point you to the right location. 💬 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.

🧩 Elementor Modules, Page Structure, and SEO

🔍 Overview If you build pages with Elementor, three common questions come up around SEO: does the Icon List module hurt rankings because it skips standard HTML list tags, do WordPress parent/child page relationships matter for SEO, and should content inside Tab modules be indexed? This article answers all three clearly so you can make informed decisions inside Search Atlas. 📋 Elementor Icon List Module and Semantic HTML Elementor's Icon List widget does not output a traditional <ul> or <ol> element. Instead, it renders a series of <div> containers styled to look like a list. Here is what that means for SEO: - Googlebot can still read the content. Google's crawler processes rendered HTML, so the text and links inside an Icon List are fully visible and indexable regardless of the wrapper element used. - Semantic signals are weaker. Native <ul> and <ol> tags communicate list structure to search engines, which can help with featured snippets and content understanding. Div-based lists do not carry the same semantic weight. - When it matters most. For pages targeting featured snippet formats — such as step-by-step guides, comparison lists, or ingredient-style content — prefer Elementor's standard Text Editor widget or a custom HTML widget that outputs real <ul> or <ol> markup. - When it is acceptable. For decorative icon lists used in hero sections, feature grids, or sidebar callouts where snippet eligibility is not a priority, the Icon List widget is fine to use. Inside Search Atlas, audit your on-page HTML structure using the Content Editor or Site Auditor. Flag pages where list-format content is a ranking priority and swap the widget accordingly. 🗂️ WordPress Parent/Child Page Structure and SEO WordPress allows you to assign a parent page to any page, creating a hierarchical URL structure such as /services/ as the parent and /services/seo-audit/ as the child. This structure has real SEO implications. - URL hierarchy signals topic relevance. A nested URL tells search engines that the child page belongs to a broader topic cluster. This can reinforce topical authority when your site architecture matches your content strategy. - Parent pages inherit linking equity. Internal links pointing to a parent page pass some authority to child pages through the site's crawl path, but this is not automatic — you still need explicit internal links between related pages. - Hierarchy alone does not replace internal linking. Do not rely solely on the parent/child relationship to connect pages. Add contextual internal links within your body copy. Search Atlas's Internal Link Suggestions tool surfaces opportunities to link parent and child pages together more effectively. - Flat vs. deep structures. A flat architecture — where most pages are within one or two clicks from the homepage — generally performs better for crawlability. Avoid nesting pages more than three levels deep unless your site scale genuinely requires it. - Breadcrumbs amplify the hierarchy signal. Enable breadcrumb schema (via Yoast, Rank Math, or a custom plugin) on parent/child page sets. Search Atlas's Schema Markup audit will flag pages missing breadcrumb structured data. Use Search Atlas's Site Audit tool (accessible from Left sidebar → Site Audit) to review your crawl depth report and confirm that child pages are being discovered and indexed correctly. If child pages are orphaned — meaning no internal links point to them beyond the parent relationship — add contextual links from the parent page body. 🗃️ Elementor Tab Modules, Content Indexing, and Noindex Strategy Elementor's Tabs widget hides inactive tab panels using CSS (display: none or similar). Google has confirmed it can index content inside hidden CSS tabs, but there are nuances you should understand before deciding on a noindex strategy. - Google does index tab content. Since Google renders JavaScript and CSS, content inside inactive tabs is generally crawled and indexed. You do not need to noindex tab panels by default. - Hidden content may receive less weight. Some SEO professionals report that content not visible on page load is treated as lower priority. If a tab contains your primary keyword content, consider whether it should be the default active tab or moved into the main page body instead. - Do not noindex individual tab panels. You cannot reliably noindex a tab panel without noindexing the entire page. Applying a noindex directive to a page removes all of its content from the index, including the visible content — this is rarely the right move. - Use tabs for supplementary content. Tabs work well for FAQs, technical specifications, or secondary information that supports the main topic but does not need to rank independently. Avoid placing your core optimised content exclusively inside a tab. - Structured data still applies. If your tab content contains FAQ pairs or how-to steps, you can still apply FAQ or HowTo schema to that content. Search Atlas's Schema Markup tool will help you validate the output even if the content renders inside a tab. To audit how Googlebot sees your tabbed pages, use the URL Inspection feature in Google Search Console alongside Search Atlas's On-Page SEO Checker. Compare the rendered HTML against your target keywords to confirm the tab content is being picked up correctly. ✅ Quick Reference Summary - Icon List widget: Use for decorative lists; switch to native HTML lists for snippet-targeted content. - Parent/child pages: Hierarchy reinforces topical clusters, but always add explicit internal links — do not rely on URL structure alone. - Tab modules: Content is indexed but may carry less weight; keep primary optimised content visible on page load and avoid noindexing pages just because they use tabs. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🌍 Managing Different Alt Text for the Same Image on Multilingual Pages

The Scenario You have a multilingual website. Your English and French content live on separate URLs, for example: - /blogs/... - /fr/blogs/... Both pages use the same featured image file. You want: - English alt text on English pages - French alt text on French pages But you notice that Search Atlas saves only one alt tag, applying it to both pages. So how does this work? ❗ Important: How Search Atlas Handles Image Alt Text Within Search Atlas, alt text is not managed per language variation of the same image file. If the same image asset is reused across multiple pages, Search Atlas will store and optimize one alt attribute for that image, not separate language-specific versions. This means: - The system does not differentiate alt text by language context - It does not create page-specific alt variations for the same image file - It applies one optimized alt value across all instances of that image This behavior is confirmed by our support team. 🤖 What About OTTO SEO? OTTO SEO optimizes alt text at the page level when processing content. However: If your CMS reuses the exact same image file across multiple pages, OTTO cannot assign two different alt attributes to the same image asset inside Search Atlas. Alt text variation by language must be handled at the CMS or site architecture level. ✅ The Correct Way to Handle Multilingual Alt Text If you need: - English alt text for /blog/... - French alt text for /fr/blog/... You must configure this directly in your CMS. Your CMS must: - Serve alt text dynamically based on language - Or use separate image entries for each language version - Or manage localized media fields Search Atlas will then read and optimize what exists per page. But it cannot create separate alt values for one shared image file inside the platform. 🔎 Why This Happens Alt text is an HTML attribute tied to the image element on the page. If your CMS outputs: <img src="image.jpg" alt="Ice bath comparison"> That alt attribute must be controlled at the page or CMS template level. Search Atlas does not override multilingual logic per asset. 🧩 Recommended Setup for Multilingual Sites To ensure proper SEO for English and French versions: 1. Use hreflang tags correctly 2. Ensure each page has self-referencing canonicals 3. Configure language-specific alt text directly in your CMS 4. Allow OTTO to crawl both language versions separately Once structured properly, OTTO will optimize each page within its language context, but only if your CMS outputs different alt text. 🎯 Final Answer If the same image file is reused on English and French pages, and you need different alt text per language: 👉 This must be implemented manually in your CMS. 👉 Search Atlas does not support storing multiple alt variations for one image asset. If you’re configuring multilingual SEO and want to confirm your setup is optimal, our team can review your structure and recommend best practices. You're thinking about this the right way, and that's what strong international SEO looks like. 🌍

🔍 Site Audit Keywords, Metrics, and FAQ Schema Explained

🗺️ Overview The Site Audit tool surfaces a lot of data at once, and three questions come up often: how to add keywords to a Site Audit report, what the page metrics are actually showing, and why FAQ schemas appear even when you never created them. This article answers all three. 🔑 Adding Keywords to Your Site Audit Report The Site Audit report does not have a field where you manually add or import keywords. The keyword data shown inside the report reflects keywords that are already detected by Search Atlas based on your site's current organic and paid search presence. Here is what each keyword category means in that context: - Organic Keywords — search terms for which Google currently ranks one or more of your pages. - Paid Keywords — search terms for which your site is running active paid ads. These numbers update automatically as your rankings change. You cannot manually add a keyword to this view, because it is a reflection of live data, not a custom list. If you want to track specific keywords and monitor their ranking over time, use the Rank Tracker tool: 1. In the left sidebar, click Keywords. 2. Select Rank Tracker (Keyword Rank Tracker). 3. Add the keywords you want to monitor for your domain. Rank Tracker is the correct place to build and manage a custom keyword list tied to your site's performance. For keyword research and discovery, you can also explore Keyword Magic and Keyword Gap under the same Site Explorer section in the sidebar. 📊 What the Page Metrics in Site Audit Display When you open the Site Audit report and view the pages listed, those pages represent URLs that are currently ranking in Google search results for your domain — not pages you have manually added or submitted. This is an important distinction. Search Atlas discovers and displays pages based on what Google has indexed and is actively surfacing in organic results. Common metrics shown for each page include: - Organic Traffic — estimated monthly visits driven by organic search. - Ranking Keywords — the number of keywords for which that URL ranks. - Backlinks — the number of external links pointing to that page. - Domain Rating (DR) — the authority score of your domain at the time of the last crawl. - Page Health Indicators — flags for technical issues such as missing meta descriptions, slow load times, or broken links. If a page on your site is not appearing in the report, it most likely means Google has not indexed it yet, or it is not currently ranking for any detectable keywords. Publishing the page, improving its content, and building internal links to it can help Google discover and rank it over time. ❓ Why Google Detects FAQ Schemas You Did Not Set Up Seeing FAQ schema data in your Site Audit report when you never deliberately added structured data to your site can be surprising. Here is why it happens. Google's systems automatically interpret page content and may generate or infer FAQ-style structured data from the way your content is written — particularly if your page uses a question-and-answer format, accordion sections, or heading structures that resemble an FAQ layout. Search Atlas reports what Google has actually detected and associated with your pages, not only what you have explicitly coded. This means: - If your content uses headers phrased as questions followed by answers, Google may classify that as FAQ schema. - Your CMS or theme may be automatically outputting structured data markup that you are not aware of. - A plugin or template component could be generating JSON-LD or microdata in the background. To investigate the source of the detected FAQ schema on a specific page: 1. Open the page URL in a browser. 2. Right-click and select View Page Source. 3. Search for FAQPage or application/ld+json in the source code. 4. Alternatively, paste the URL into Google's Rich Results Test to see exactly what structured data Google is reading. If you want to remove the FAQ schema, you will need to edit or disable the plugin, theme component, or code block that is generating it. If you want to keep and enhance it, Search Atlas's OTTO SEO tool (left sidebar → OTTO SEO → All Sites (SEO Automation)) can help you optimise your structured data as part of your on-page SEO workflow. ⚡ Quick Reference - To track specific keywords → Left sidebar → Keywords → Rank Tracker - To research new keywords → Left sidebar → Keywords → Keyword Magic or Keyword Gap - To investigate detected schemas → View page source or use Google's Rich Results Test - To optimise on-page SEO including schema → Left sidebar → OTTO SEO → All Sites (SEO Automation) If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Export 404 URLs from Site Audit for Redirects

🗺️ Overview If your Site Audit has flagged hundreds of broken pages, exporting those 404 URLs is the first step toward building a redirect map. This article walks you through locating the correct section in Site Audit, filtering for 404 errors, and downloading the full list. 🔎 Step 1: Open Your Site Audit Project 1. In the left sidebar, click OTTO SEO → Site Audit. 2. Locate the project tied to your domain and click into it to open the Site Audit dashboard. 3. Confirm the audit has finished running. If data is still loading, wait for the progress indicator to complete before proceeding. ⚠️ Step 2: Navigate to the Broken URL Data The 404 broken page data lives inside the issues or errors section of Site Audit. Look for a section or category related to broken pages or 4xx errors — the exact label may vary depending on your account configuration. 1. Inside your Site Audit project, navigate to the section that lists crawl issues or page errors. 2. Scroll through or search the issues list to find the category related to broken or unreachable pages (4xx errors). 3. Click that issue category to expand the full list of affected URLs. 📥 Step 3: Export the 404 URL List 1. Once the broken URL list is visible, look for an Export option associated with the table or list view. 2. Click Export to download the list as a CSV file. 3. The CSV will include each broken URL, making it straightforward to paste into a redirect mapping spreadsheet. Note: If you have trouble locating the export option or the list does not appear as expected, try refreshing the page and allowing the audit data to fully load before trying again. 🗂️ Step 4: Use the Exported Data to Map Redirects Once you have your CSV, you can build your 301 redirect map by matching each broken URL to its correct replacement destination. A few tips to speed up the process: - Group by URL pattern — URLs that share a common path segment (e.g., /blog/old-category/) can often be redirected with a single rule. - Prioritise by traffic — Cross-reference the 404 list with your analytics data to fix your highest-traffic broken pages first. - Use OTTO SEO — After implementing redirects, re-run the Site Audit to confirm the 404 errors have been resolved. 💡 Tips and Troubleshooting - If you do not see any broken page issues listed, check that the audit has fully completed. Large sites with hundreds of pages can take several minutes to crawl. - If you manage multiple sites, make sure you are inside the correct project for the domain you want to fix before exporting. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Fix Keyword Cannibalization and Unindexed Pages

🧭 Overview Keyword cannibalization happens when two or more pages on your site compete for the same keyword, splitting ranking signals and confusing search engines about which page to show. Separately, you may notice pages that appear unindexed even when OTTO reports no critical issues. This article explains both scenarios and walks you through how to approach investigating them inside Search Atlas. 🤔 Why Does OTTO Say Everything Is Okay If I Still Have Problems? OTTO's audit evaluates your site against a prioritized checklist of SEO tasks and surfaces the most impactful fixes first. A clean OTTO status means no high-priority blockers are currently queued — it does not guarantee that every page on your site is indexed or that zero cannibalization exists. Some issues only become visible after deeper analysis in the supporting tools. Use the workflow below to investigate further. 🔍 Step 1 — Identify Keyword Cannibalization 1. Navigate to the Rank Tracker tool inside Search Atlas. 2. Filter your tracked keywords and look for the same keyword appearing under multiple URLs. When more than one URL ranks for the same term, that is a cannibalization signal. 3. For a broader view, use the keyword analysis tools available in Search Atlas to compare your pages against each other or against competitors and identify overlapping keyword clusters. 4. Make a note of every conflicting URL pair before moving to the fix stage. 🛠️ Step 2 — Address Cannibalization Once you have identified competing pages, common remediation strategies include: - Consolidating content — merge the weaker page's content into the stronger page so a single authoritative URL covers the topic. - Adding a canonical tag — add a self-referencing canonical on the preferred page and a canonical pointing to that preferred page on any duplicates, signaling to search engines which URL should receive ranking credit. - Implementing a 301 redirect — redirect the weaker URL permanently to the stronger one so all ranking signals are consolidated. After applying any of these fixes externally, monitor ranking changes in Rank Tracker over the following two to four weeks to confirm the primary page begins consolidating ranking signals. If you are unsure which approach is appropriate for your site or how to implement these changes, our support team can help point you in the right direction. 📊 Step 3 — Investigate Unindexed Pages If pages remain unindexed after OTTO shows a clean bill of health, the cause is usually outside OTTO's direct control. Work through these checks: - Google Search Console (GSC): Open GSC and navigate to Pages under the Indexing report. The reason code next to each unindexed URL (e.g., Crawled — currently not indexed, Duplicate without canonical, Blocked by robots.txt) tells you exactly what Google is seeing. - Canonical tags: If GSC shows a Duplicate without canonical error, add a self-referencing canonical tag to the affected page so Google knows which URL is authoritative. - Robots.txt and noindex directives: Confirm the page is not blocked by a robots.txt disallow rule or a noindex meta tag, either of which would prevent Google from indexing it regardless of OTTO's status. - Crawl budget: For large sites, Google may deprioritize crawling thin or low-value pages. Improving internal linking to the affected pages can help signal their importance. 📋 When to Escalate If you have worked through the steps above and pages remain unindexed or cannibalization persists, please have the following ready when you contact support so we can investigate efficiently: - Your project name in Search Atlas - The specific URLs affected (both competing URLs for cannibalization, or the unindexed URL) - The exact error or reason code shown in Google Search Console - Any canonical or redirect changes you have already applied and when you applied them If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Resolve Climate Audit Content Flags

🌡️ What These Audit Flags Mean Climate-audit and active sitemap reviews can identify pages with repeated FAQ content or missing content sections. These flags describe structural patterns, not automatic proof that every page needs the same fix. A page may be flagged because its template is incomplete, content did not load during the scan, or similar sections were published more than once. 📊 Validate the Scope First Before editing pages, confirm the findings against the live site and the current sitemap: 1. Open OTTO SEO → All Audits or OTTO SEO → Crawl Monitoring to review the audit results. 2. Compare the staging findings with live production pages. 3. Confirm whether the reported count matches pages currently listed in the active XML sitemap. 4. Separate results into high-confidence duplicate FAQ pages, medium-confidence structure issues, and clean pages. 5. Manually review a representative sample so decisions are not based only on automated detection. Counts can differ between audit screens when scans, sitemap data, or domain analysis are still updating. Refresh the audit after the crawl and sitemap data are available. Previously reported sitemap scheme and duplicate-row issues may also affect older results. 🧩 Define the Correct Page Structure Choose five to ten representative pages across templates, locations, and issue types. Compare them with approved reference pages, such as Glendale AZ, Tucson AZ, or Boston. Document the intended structure before making bulk changes. For each template, decide how to handle: - Duplicate FAQ content: retain one accurate FAQ section and remove or rewrite repeated copies. - Intro copy: keep a clear, unique introduction that matches the page location and intent. - “Common Plumbing Challenges”: retain it only when it adds useful, page-specific information. - Missing content3Summary, wcrrContent, or content7Summary: determine whether the field is required for that template or should remain intentionally empty. - Pages needing substantial changes: mark them for rewrite or rebuild instead of applying a mechanical fix. 🧪 Run a Staging Pilot Repair a small batch of approximately 10–25 pages in staging. Include different templates and severity levels. After the changes: 1. Refresh the site or audit cache. 2. Review the rendered pages, not only the stored content fields. 3. Check headings, intro copy, FAQ placement, section order, links, and page-specific details. 4. Compare before-and-after results and record any pages that still need manual rewriting. 5. Keep an export or rollback copy of every changed row. 🚀 Roll Out Repairs in Waves After the pilot passes QA, remediate pages in controlled waves. Prioritize active sitemap pages, then address high-severity findings before medium-severity structure issues. Run every wave through staging and QA before promoting it to production. Continue monitoring the sitemap and rerun the audit after each release. 📌 Set Practical Expectations A small climate-audit set, such as 70 pages, may be fixable within a week when the scope is limited and the repair recipe is clear. A set of 2,475 high-severity active sitemap pages is not suitable for manual cleanup in one week. A broader set of 3,760 pages with any structural flag requires automated or semi-automated remediation, staged testing, and multiple review waves. 🛠️ Where to Review and Create Content Use OTTO SEO → All Audits for audit findings and Content → Content Genius for page rewrites or new content. Content Genius includes options to write, generate, rework, or create content in bulk. Use bulk actions only after the target structure has been approved and the pilot confirms that the output is accurate. 💬 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.

🔄 Replace an SEO Project Domain Without Losing Data

🗺️ Overview Sometimes you need to move an SEO project to a new domain — whether you're rebranding, migrating a site, or correcting an initial setup error. Search Atlas does not allow you to directly overwrite an existing project's domain, but this guide walks you through the safest approach to make the switch while preserving as much of your data as possible. ⚠️ What Happens to Your Data Before you begin, it's important to understand how data is stored in Search Atlas: - Keyword rankings, tracked keywords, and rank history are tied to the specific domain in your project. These cannot be automatically transferred to a new domain. - Backlink data, site audit results, and reports are also domain-specific and will not carry over automatically. - Project settings, notes, and configurations (such as target location, language, and competitors) can be manually re-applied to a new project. Because of this, the recommended workflow is to export your key data before making any changes, then set up a new project for the new domain. 📋 Step 1 — Export Your Existing Project Data Before touching anything, export the data you want to preserve from your current project: 1. Open your existing SEO project in Search Atlas. 2. Navigate to the Rank Tracker and export your tracked keyword list and ranking history using the export or download option. 3. Go to the Site Auditor and download any audit reports you want to reference later. 4. Visit the Backlink Analyzer and export your backlink profile if needed. 5. Take note of your project settings: target country, city, language, search engine, and any competitors you've been tracking. Save all exported files in an organised folder so they're easy to reference when setting up your new project. ➕ Step 2 — Create a New Project for the New Domain Once your data is safely exported, create a fresh project for the new domain: 1. From the Search Atlas dashboard, navigate to Home → Create Project. 2. Enter your new domain name and fill in all relevant settings (location, language, competitors) using the notes you saved in Step 1. 3. Save the project to initialise data collection for the new domain. 📥 Step 3 — Re-import Your Keywords To restore your tracked keywords in the new project: 1. Open the Rank Tracker inside your new project. 2. Use the Import Keywords option to upload the keyword list you exported from the old project. 3. Confirm the import and allow Search Atlas to begin tracking rankings for those keywords on the new domain. Note that historical ranking data from the old domain cannot be migrated — the new project will start building fresh ranking history from the date of import. 🗑️ Step 4 — Archive or Delete the Old Project Once your new project is set up and tracking correctly, decide what to do with the old project: - Archive it if you may need to reference its historical data in the future. - Delete it if you're certain you no longer need it and want to free up a project slot. To delete a project, go to your project settings, scroll to the bottom, and select Delete Project. This action is permanent, so make sure your exports are complete before proceeding. 💡 Tips for a Smooth Transition - Run a fresh site audit on the new domain immediately after creating the project to establish a baseline. - Re-add the same competitors you were tracking in the old project so your competitive data stays consistent. - If you use Search Atlas reports to share progress with clients, update any saved report templates with the new project's data source. - Allow 24–48 hours for initial ranking data to populate in the new project before drawing conclusions. 🆘 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.

🗂️ Site Lens 3D Crawl Graph Rendering Improvements

Site Lens has received updates to its 3D crawl-graph as part of a recent improvement release (2026-07-22). This update addresses rendering improvements to the 3D crawl-graph visualization within Site Lens. ✨ What Changed The 3D crawl-graph in Site Lens received rendering improvements in this release. If you have noticed a change in how the 3D crawl-graph looks or behaves — such as differences in how nodes, edges, or site structure are displayed — these changes are expected and part of this update. 🛠️ Steps to Check the Updated 3D Crawl-Graph 1. Open OTTO SEO → Site Audit → Site Lens in Search Atlas. 2. Select your project or site from the project selector at the top of the page. 3. Navigate to the 3D Crawl Graph view within Site Lens. 4. If the graph does not load as expected, try refreshing the page or clearing your browser cache, then reload. 5. If you see unexpected behavior — such as nodes not rendering, broken edges, or missing data — note the specific site or project name, what you expected to see, and what you are seeing instead, then contact our team with those details. 📋 If You Still Have Questions If the behavior you are seeing does not match your expectations after reviewing the updated graph, please have the following ready before reaching out: - Your project or site name in Search Atlas - A description of what you are seeing versus what you expected - Any screenshots that illustrate the behavior in question - The approximate date and time you first noticed the change If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔄 How to Recrawl Your Website

This article explains how to start a new website crawl, manually reprocess the results, and confirm that updated data is available. 🛠️ Step-by-Step 1. Open the project containing the website you want to refresh. 2. Open the website's crawl or processing controls. 3. Select the option to start a new recrawl, then confirm the action. 4. Wait for the crawl to finish so the latest pages and website data are collected. 5. After the crawl completes, select the option labeled Manual reprocess or equivalent to process the newly collected data. 6. Allow processing to complete before reviewing reports or other results. ✅ How to Confirm It Worked Check that the crawl and processing statuses show as completed, the latest crawl or processing timestamp has updated, and refreshed website data appears in the relevant results. If an error appears or the timestamp does not change, retry after the current job finishes. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

CloudStack: Keywords, Knowledge Pages, and Crawling

Overview CloudStack uses your website's knowledge pages and keyword inputs to power AI-driven content and SEO workflows. Two common points of confusion are: (1) why CloudStack sometimes does not pull data from your knowledge page, and (2) whether long-tail keyword phrases are acceptable inputs. This article addresses both questions directly. Why CloudStack May Not Pull from Your Knowledge Page CloudStack crawls your designated knowledge pages automatically, but certain conditions on the page itself can prevent it from accessing or indexing the content correctly. Common reasons include: - Noindex tags: If the page contains a noindex meta tag or header, CloudStack will respect that directive and skip the page. Check your page's HTML <head> section for <meta name="robots" content="noindex"> and remove it if you want the page crawled. - Blocked by robots.txt: If your robots.txt file disallows crawling for the relevant path, CloudStack cannot access the page. Review your robots.txt at yourdomain.com/robots.txt and ensure the path to your knowledge page is not disallowed. - JavaScript-rendered content: Pages that load content exclusively via JavaScript may not be fully accessible to CloudStack's crawler. If your knowledge page relies on client-side rendering, consider providing a static or server-rendered version of the content. - Incorrect URL entered: Double-check that the knowledge page URL entered in your CloudStack configuration exactly matches the live page URL, including any trailing slashes or subdirectory paths. To diagnose the issue, start by visiting the knowledge page URL you entered in CloudStack, confirming it loads correctly, and then checking for noindex tags and robots.txt restrictions. Using Long-Tail Keywords in CloudStack CloudStack accepts long-tail keyword phrases as valid inputs — you are not limited to single words or short two-word combinations. Long-tail keywords (typically three or more words that reflect a specific search intent) are supported in CloudStack's keyword input fields. To use them correctly: 1. Navigate to your CloudStack keyword configuration panel. 2. Enter the full long-tail phrase as a single keyword input (for example, "best project management software for small teams"). 3. Avoid splitting a long-tail phrase across multiple separate keyword fields — enter it as one complete phrase per field. 4. Save your configuration and allow CloudStack to process the updated keyword list before evaluating results. If your keyword inputs are not being recognized or your knowledge page continues to be skipped after following the steps above, please have the following ready when contacting support: your knowledge page URL, any error messages shown in CloudStack, and the exact keyword phrases you are trying 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.

What Factors Affect Your Website's Crawl Budget?

⚙️ What Factors Affect Your Website's Crawl Budget? Google does not crawl all websites equally. The amount of crawling attention Googlebot dedicates to your site — your crawl budget — is shaped by a combination of technical signals, authority metrics, and site health indicators. Understanding these factors helps you make informed decisions about how to improve your site's crawlability and search performance. 🔎 📐 The Two Core Components of Crawl Budget According to Google's official documentation, crawl budget is determined primarily by two interacting components: crawl rate limit and crawl demand. These two factors work together to define how frequently and how aggressively Googlebot will explore your site. ⚡ Crawl Rate Limit The crawl rate limit defines how fast Googlebot can request pages from your server without causing performance issues or overloading your infrastructure. Think of it as the speed governor on Googlebot's crawling engine — it prevents the crawler from sending so many simultaneous requests that your server slows down or crashes. ✅ Server response time is one of the most direct influences on crawl rate limit. If your server responds to requests quickly and consistently, Googlebot can safely crawl more pages per unit of time. ✅ Host load also matters — if your server is under heavy traffic from real users, Googlebot will back off to avoid making the situation worse. ✅ Server errors (5xx responses) are a strong negative signal. When Googlebot encounters repeated server errors, it reduces its crawl rate to protect your site, which means fewer pages are crawled overall. ⚡ You can influence the crawl rate limit directly through Google Search Console (Settings → Crawl Rate) by requesting that Google crawl your site more slowly or more quickly within a 90-day window. However, the most sustainable improvement comes from improving actual server performance. 📈 Crawl Demand Crawl demand reflects how much Google wants to crawl your URLs — independent of your server's capacity. Even if your server could handle millions of requests per day, Google will only invest crawl capacity in pages it considers worth revisiting. Crawl demand is driven by several factors: ✅ Link authority and PageRank — Pages with more high-quality inbound links signal greater importance to Google. Higher PageRank translates directly into higher crawl demand, as Google wants to keep authoritative pages fresh in its index. ✅ Content freshness and staleness — Pages that are updated frequently (news articles, product listings, blog posts) generate higher crawl demand because Google wants to capture the latest version. Pages that never change may be crawled less often over time. ✅ Overall site popularity — Websites that attract significant organic traffic, earn natural backlinks, and demonstrate strong engagement signals tend to receive more generous crawl budgets because Google recognizes them as valuable resources worth indexing thoroughly. ⚡ Key insight: You cannot directly instruct Google to increase crawl demand — it must be earned through building genuine authority, earning quality backlinks, and publishing content that is regularly updated and valuable to users. 🏆 🏗️ Site Size and Architecture The sheer size and structural complexity of your website has a direct impact on how efficiently Googlebot can spend its allocated crawl budget. ✅ Large websites with hundreds of thousands of URLs naturally take longer to crawl in full. If your crawl budget is limited relative to your URL count, some pages will inevitably be crawled less frequently or not at all. ✅ Deep site architecture — where important pages are buried many clicks away from the homepage — makes it harder for Googlebot to discover and prioritize content efficiently. Flatter architectures that keep key pages within three clicks of the homepage perform better. ✅ Orphan pages with no internal links pointing to them may never be crawled, regardless of their content quality, simply because Googlebot has no path to reach them. 🚨 Site Health Factors That Drain Crawl Budget Beyond the two core components, several common site health issues can silently consume large portions of your crawl budget without contributing any SEO value. ✅ 4xx error pages (page not found) waste a crawl request every time Googlebot tries to access a broken URL. At scale, a large number of broken URLs can meaningfully reduce the crawl capacity available for your live, indexable content. ✅ 5xx server errors not only waste individual crawl requests but actively signal to Googlebot that your server is unreliable, causing it to throttle its crawl rate further. ✅ Redirect chains — sequences of multiple redirects between an original URL and its final destination — force Googlebot to spend multiple crawl requests to reach a single piece of content. A single 301 redirect is acceptable, but chains of two or more hops should be flattened. ✅ Slow page load times reduce how many pages Googlebot can fetch in a given crawl window. If every page takes three seconds to load, Googlebot will crawl far fewer pages than it would on a server delivering sub-second responses. ✅ Duplicate content across multiple URLs forces Googlebot to spend crawl budget processing the same information repeatedly. Using canonical tags and avoiding unnecessary URL parameter variations helps consolidate crawl signals efficiently. 🎯 🤔 Does Crawl Budget Matter for Every Website? Google has noted that crawl budget is most critical for large websites — typically those with hundreds of thousands of URLs or more — as well as sites that update content very frequently. For smaller websites with a few hundred pages and a healthy site structure, crawl budget is rarely a limiting factor. ✅ If your site has fewer than a few thousand pages and all important content is being indexed regularly, crawl budget optimization is unlikely to be a priority concern. ✅ If your site has large-scale content (e-commerce catalogs, news archives, user-generated content), crawl budget management becomes a critical technical SEO discipline that directly impacts how much of your content appears in search results. 🔍 Bottom line: Crawl budget is shaped by factors you can control (server performance, site architecture, redirect efficiency, content quality) and factors you earn over time (authority and popularity). Addressing the controllable factors first creates the foundation for a more efficient, scalable crawl. ⚡

🖼️ Force Search Atlas to Recrawl and Reprocess Images

🔍 Why Search Atlas Still Shows Old Image Data When you replace images on your website — for example, swapping PNG files for JPEGs — Search Atlas may continue displaying the previous image attributes, including outdated alt text, file types, or URLs. This happens because Search Atlas stores a cached snapshot of your site from its last crawl. Clearing your CMS cache or CDN cache does not automatically trigger a new crawl inside Search Atlas. You need to manually instruct the platform to re-fetch and reprocess your images. 📋 What You Will Need - Access to your Search Atlas account - Your CMS and CDN caches already cleared before triggering a new crawl - The target site added and verified inside Search Atlas 🚀 Step 1 — Trigger a Manual Recrawl To force Search Atlas to pick up your updated images, you need to trigger a new crawl of your site from within the platform. Navigate to your site inside Search Atlas and look for the option to manually start or re-run a crawl. Initiate that crawl and allow it to complete before moving to the next step. Depending on your site size, the recrawl can take anywhere from a few minutes to several hours. Wait until the crawl status shows as complete before reviewing your image data. ⚙️ Step 2 — Reprocess Image Data After the recrawl completes, Search Atlas needs to reprocess the updated image data so that new alt texts, file types, and attributes are correctly reflected across all reports. Within your site's reporting area, look for an option to re-run or refresh the analysis. Trigger that reprocessing action and wait for it to finish before checking your results. 🧹 Step 3 — Confirm Your External Cache Is Cleared Before verifying results inside Search Atlas, confirm that your external caches are genuinely cleared and serving the new image files. Stale responses from a CDN or browser cache can cause the Search Atlas crawler to re-fetch the old image even after a recrawl is triggered. - CDN (e.g., Cloudflare): Use your CDN provider's cache purge feature to clear the affected image URLs or purge all cached assets. - CMS (e.g., WordPress): Clear both your plugin-level cache and any server-side page cache. - Browser: Open the image URL directly in an incognito window to verify the new file is being served before re-triggering the crawl. 📞 Still Seeing Stale Image Data? If your images are still showing outdated attributes after completing the steps above, our support team can investigate further. When escalating, please have the following ready: your site's project name in Search Atlas, the specific image URLs affected, the approximate time you replaced the files, and confirmation that your external caches have been cleared. If you need further assistance, open 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 Indexer Plan Requirements and Quota Guide

🗺️ Overview The URL Indexer feature lets you submit URLs directly for faster search engine indexing. Access to this feature depends on your current Search Atlas plan. If your plan does not include URL Indexer, attempting to use or add quota may trigger an HTTP 500 error — this is a plan eligibility issue, not a technical bug. 📋 Which Plans Include URL Indexer? URL Indexer is available on select Search Atlas plans. Not all plan tiers include access to this feature. If you are on an ineligible plan, the feature will be inaccessible and any attempt to add quota may return an HTTP 500 error. To confirm whether your specific plan includes URL Indexer, review your plan details in your account's billing or subscription settings, or contact our support team for clarification. ⚠️ Why Am I Seeing an HTTP 500 Error? An HTTP 500 error when attempting to add Indexer Quota is almost always caused by plan ineligibility, not a platform bug. Specifically, this error can appear when: - Your current plan does not include the URL Indexer feature. - You attempt to purchase or allocate additional Indexer Quota without an eligible base plan. Before troubleshooting the error further, confirm that your plan includes URL Indexer access. If it does not, upgrading your plan is the required first step. 📍 How to Find the URL Indexer If your plan includes URL Indexer, you can access it from within the Search Atlas platform. If the option is missing from your navigation or returns an error when clicked, your current plan likely does not include this feature. ➕ Can I Purchase Indexer Quota Separately? Indexer Quota is an add-on that can be purchased in addition to your existing quota, but it is only available on eligible plans. You cannot purchase standalone Indexer Quota without an active eligible plan. 🔄 How to Resolve the HTTP 500 Error 1. Confirm your current plan by navigating to your account billing or subscription settings. 2. If your plan does not include URL Indexer, upgrade to an eligible plan tier to unlock the feature. 3. Once on an eligible plan, navigate to the URL Indexer section within the platform to access the feature. 4. To add more quota, use the quota management option within the URL Indexer page. 5. If the HTTP 500 error persists after confirming you are on an eligible plan, contact support for further investigation. 💡 Key Reminders - URL Indexer is not available on all plan tiers — check your subscription to confirm eligibility. - Upgrading your plan is required to unlock URL Indexer if your current plan does not include it. - Indexer Quota add-ons require an eligible base plan to purchase. If you need further assistance, open 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 Initiate a Recrawl and Manual Reprocess

This article explains how to initiate a recrawl of your website and manually reprocess your site data. Use these steps when your site's data feels stale, when recent changes aren't reflected in your reports, or when you've been advised by support to force a fresh crawl and reprocess cycle. 🛠️ What to Do If your site data appears outdated or recent changes are not showing up in your reports, you can request a recrawl and manual reprocess through the platform. The exact controls for triggering a recrawl and reprocess vary depending on your project setup and the tools you have access to. To get started, navigate to the relevant project or website in Search Atlas. From there, look for crawl or audit-related options within your project area. If you are unsure where to find these controls or if you cannot locate an option to trigger a recrawl or reprocess, a member of our support team can initiate a backend reprocess on your behalf. ✅ What to Have Ready When You Reach Out To help our team resolve this as quickly as possible, please have the following information ready before contacting support: - The name of the project or domain you need recrawled or reprocessed - A description of what data appears stale or incorrect (e.g., page counts, scores, issue lists) - Approximately when you last saw the data update correctly - Any recent changes you made to your site that should now be reflected If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Set Up Crawl Monitoring on GoDaddy Sites

Overview If your site is hosted on GoDaddy as a static HTML site and you are not using Cloudflare, you can still set up crawl monitoring in Search Atlas. Because GoDaddy static HTML sites do not use a CMS plugin or Cloudflare Worker, the recommended path is to add a monitoring script manually to your HTML files. This article explains what that generally involves and tells you exactly what to have ready if you need our team to walk you through your specific setup. General Approach The topic of setting up crawl monitoring on a GoDaddy static HTML site without Cloudflare is one where configurations vary significantly by account and hosting plan. Because no single universal step-by-step flow applies to every GoDaddy setup, the steps below describe the general approach — but our team can confirm the exact steps and UI elements for your specific account. In general, setting up script-based crawl monitoring on a static HTML site involves: - Locating the monitoring script or snippet provided by Search Atlas for your project. - Adding that script tag to your HTML files — typically placed before the closing </head> tag — starting with your main index.html file at a minimum. - If your GoDaddy plan uses a Website Builder editor rather than direct file access, looking for an option to add custom code or custom header code, which would allow you to apply the script site-wide without editing individual files. - If you manage files directly, uploading the updated HTML files via GoDaddy's file manager or via FTP/SFTP. - Once your updated files are live, checking within your Search Atlas project that monitoring is active for your site. Important: The exact names of options, tabs, and settings in both the Search Atlas dashboard and your GoDaddy hosting control panel depend on your specific plan and account configuration. If you cannot locate the script or the correct place to paste it, please reach out to our team — we can confirm the exact steps for your setup. What to Have Ready When You Contact Us To help our team resolve your issue as quickly as possible, please have the following ready before reaching out: - Your Search Atlas project name and the full URL of the GoDaddy site you are trying to monitor - Whether you are using GoDaddy's file manager, FTP/SFTP access, or the GoDaddy Website Builder editor - A description of where in the process you are getting stuck, including any error messages or labels you see on screen - Whether you have already attempted to add any script tag to your HTML files, and if so, which pages you updated If you need further assistance, open 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 Quota vs. Site Audit Quota Explained

🧭 Overview Search Atlas uses two separate quota systems that are often confused with each other: OTTO site quota and site audit quota. Upgrading one does not affect the other. If you are seeing a 'quota full' error after an upgrade, this article will help you identify which quota you actually hit and what to do next. 📋 What Is OTTO Site Quota? Your OTTO site quota controls how many websites you can activate and manage inside the OTTO SEO automation tool. - Each site you connect to OTTO and set live counts as one OTTO site slot. - Removing a site from OTTO frees up that slot for a different domain. 📊 What Is Site Audit Quota? Your site audit quota controls how many websites you can add to the site audit section of the platform. This section powers your site crawls, technical audits, rank tracking, and keyword data. - Each domain you add uses one site audit slot. - Site audit slots and OTTO slots are tracked independently. - Having an available OTTO slot does not mean you have an available site audit slot, and vice versa. ⚠️ Why the 'Quota Full' Error Appears The 'quota full' error appears when you attempt to add or activate a site and there are no remaining slots in the specific quota that action requires. The two most common scenarios are: 1. You upgraded your OTTO site quota but the error is in the site audit section. Adding a domain to site audits requires a site audit slot, not an OTTO slot. Upgrading OTTO quota will not resolve this error. 2. You upgraded your site audit quota but the error is in OTTO. Activating a domain inside OTTO requires an OTTO slot. Upgrading site audit quota will not resolve this error. 🔍 How to Check Which Quota You Have Hit To identify which quota is exhausted, compare the number of domains you currently have active in each area against the limits shown on your plan. Check OTTO and site audits separately — they are tracked independently. Whichever area has no remaining slots is the quota you have hit. ✅ How to Resolve a Quota-Full Error Once you have identified which quota is full, you have two options: - Free up a slot: Remove a domain you no longer need from the relevant section (OTTO or site audits) to make room for the new one. - Upgrade the correct quota: Make sure you are upgrading the quota that matches the section where the error appears. Upgrading your OTTO quota resolves OTTO-related errors; upgrading your site audit quota resolves site audit errors. Upgrading the wrong quota will not clear the error. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Reset and Delete Duplicate DKN Nodes

📚 What is a DKN? A Domain Knowledge Network (DKN) organizes your site’s topics, pages, and related knowledge for SEO workflows. Duplicate or overlapping nodes can make the network harder to manage and may affect topic mapping. 🔍 Why duplicate nodes may appear Duplicates can occur when similar pages or topics are interpreted as separate entities during generation, rebuilding, or synchronization. In some cases, a failed or interrupted process may leave existing nodes in place while creating new ones. This does not always indicate a problem with your website. It may reflect how the system currently determines whether a page or topic already exists. 🧹 Request a DKN reset or cleanup There is no general bulk-delete or full-reset action that customers should use without assistance. A reset can remove the current network, so it must be reviewed before it is performed. 1. Open OTTO SEO from the left sidebar. 2. Open Knowledge Base and select the affected project or site. 3. Record the duplicate node names, related URLs, and any recent generation, rebuild, or synchronization activity. 4. Open the chat widget in the bottom-right corner of the platform and request either a full DKN reset or duplicate-node cleanup. State whether you want to preserve the existing network, remove only selected duplicates, or start with a completely empty DKN. This helps the team choose the safest option. ⚠️ Before requesting a full reset - A full reset removes the project’s current DKN data and cannot be treated as a simple undo. - Confirm the correct project and domain before approving the reset. - Pause planned rebuilds or synchronization until the request is reviewed. - Keep a list of important nodes or URLs that should be retained after cleanup. 🔄 After cleanup or rebuilding After the DKN is reset or cleaned, allow the next generation to finish before starting another rebuild or synchronization. Review the resulting nodes for overlapping topics and confirm that important pages are represented once. If nodes disappear after a rebuild or a “Sync with Brand Vault” action shows an error, do not repeatedly retry the action. Record what happened and request a review so the network can be checked before another operation. 💬 Get help with duplicate nodes Include the project name, domain, affected node names, related URLs, approximate time of the issue, and the action that preceded it. This information helps the team determine whether targeted cleanup or a complete reset is appropriate. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Understanding URL Crawl Frequency

🔍 What recrawl frequency means A recrawl frequency is the preferred interval for checking a URL again, such as every 7, 14, or 30 days. It is a scheduling preference, not a guarantee that every URL will be crawled exactly on that date. 🗓️ Why a URL may be overdue Several factors can delay a recrawl, even when a URL has a frequent schedule: - Crawl capacity: Available crawl resources are shared across projects and may affect timing. - Project eligibility: The project or URL must be active and eligible for recrawling. - Previous crawl results: Errors, blocked access, timeouts, or unavailable pages can prevent a successful recrawl. - Scheduling delays: Recrawls may run later than the selected interval when queued work or system processing affects execution. - Configuration changes: A URL may have been added, removed, or updated after the current schedule was created. ⚙️ How schedules are applied The selected frequency tells Search Atlas how often to prioritize a URL for crawling. It does not reset the URL's crawl date immediately or force a crawl at the exact interval. For example, a 7-day setting means the URL becomes eligible for recurring processing around that interval, subject to availability and access. Changing a frequency also does not necessarily trigger an immediate crawl. The next run depends on the URL's current crawl state and the platform's scheduling process. 📊 What to check when crawls are delayed 1. Open the relevant project and confirm that the project is active. 2. Check that the URL is still included in the project and has the expected recrawl frequency. 3. Review the URL's latest crawl date and any crawl status or error details. 4. Confirm that the page is publicly accessible and does not block Search Atlas or search-engine crawlers. 5. Allow additional time if the URL is queued or the latest crawl attempt was unsuccessful. 🚀 Best practices for recurring crawls - Use shorter intervals for pages that change often or are business-critical. - Use longer intervals for stable pages to focus crawl capacity where it matters most. - Keep project settings and URL lists up to date. - Fix access, redirect, server, and robots.txt issues that prevent successful crawling. - Review crawl history regularly instead of relying only on the selected frequency. 💬 Need help investigating a URL? If a URL remains uncrawled well beyond its expected interval, review its project status, crawl history, and access settings first. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🏥 YMYL Compliance for Medical Content in Search Atlas

🔍 What Is YMYL and Why Does It Matter for Medical Content? YMYL stands for Your Money or Your Life. Google applies stricter quality standards to content that could directly affect a person's health, safety, or financial wellbeing. Medical content almost always falls into this category. If your content fails to meet YMYL expectations, Google's quality raters and algorithms may downrank it — regardless of how well it is optimised for keywords. To rank well, medical content must also demonstrate E-E-A-T: Experience, Expertise, Authoritativeness, and Trustworthiness. Search Atlas does not have a dedicated YMYL compliance mode. The platform's tools are general-purpose SEO tools. Achieving YMYL compliance for medical content requires editorial decisions made by you or your team outside the platform, in addition to using Search Atlas features as part of your broader workflow. ✍️ What Search Atlas Can and Cannot Do for Medical Content It is important to set accurate expectations about what the platform provides: - Search Atlas does not automatically detect YMYL topics, flag health-related claims, or apply special rules to medical content. - The platform's content tools generate and evaluate content based on SEO signals — they do not validate medical accuracy or enforce credential requirements. - Content scoring within Search Atlas is based on keyword coverage compared to competing pages. A high content score does not indicate YMYL compliance. - Keyword research features surface search volume and competition data. They do not distinguish between medically safe and medically risky keyword choices. If you have questions about a specific Search Atlas feature and how it behaves with your medical content project, please contact our support team directly so we can advise based on your exact setup. 📋 What to Have Ready When Escalating a YMYL-Related Issue If you are experiencing a specific problem — for example, unexpected results on a medical page, content output that concerns you, or questions about how a particular tool handles health-related topics — our team can help. Please have the following ready before reaching out: - Your project name and the specific tool you are using. - The exact URL or content draft in question. - A description of the specific outcome or output that is not meeting your expectations. - Any error messages displayed, including the exact wording and the time they 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.

🚫 Exclude URLs, Rerun Audits & Track Keywords

🗺️ Overview This article walks you through four common workflow tasks in Search Atlas: excluding URL patterns from a project audit, rerunning and verifying a crawl, tracking keywords with competitor insights, and diagnosing why a specific location may not be generating recommendations. 🚫 Step 1: Exclude URL Patterns from Your Audit You can prevent specific sections of your site from being crawled by adding URL exclusion conditions in your project's OTTO SEO Settings. 1. From the left sidebar, navigate to OTTO SEO → All Sites (SEO Automation) (URL: /seo-automation-v3). 2. Open your project and click the Autopilot / Smart Crawl card at the top of the overview to open the OTTO SEO Settings modal. You can also reach it from the All Sites table by clicking the Smart Crawl status text on your site's card. 3. Scroll to the URL Exclusion conditions section and click + Add condition. 4. Set each condition to Exclude all URLs that Contains or Start With the text you want to skip. For example: - Start With /obituaries/ — excludes all pages under the /obituaries/ directory - Start With /store/ — excludes all pages under the /store/ directory 5. Click Update Settings to apply your changes. You can add multiple exclusion conditions — each one is added with its own + Add condition rule. 🔄 Step 2: Rerun the Audit Crawl After saving your exclusion rules, you need to trigger a new crawl for the changes to take effect. 1. Inside your project, navigate to Site Audit → Overview (Website Overview) and click the Recrawl Site button. 2. Confirm the action when prompted. 3. The crawl will be queued immediately. Depending on the size of your site, crawl completion can take anywhere from a few minutes to 24 hours or more for large sites with thousands of pages. How to verify the crawl has completed: - Return to your project dashboard and check the Last Crawled timestamp — it should reflect today's date and time once the crawl finishes. - Review the total pages crawled count. After exclusions are applied, this number should be lower than your previous crawl if the excluded paths contained indexed pages. - Navigate to the Crawled URLs or Pages report and confirm that no URLs containing /obituaries/ or /store/ appear in the results. If the timestamp has not updated after 24 hours, the crawl may still be processing. Large sites with extensive internal linking can take longer. Avoid triggering a second rerun while the first is still in progress, as this may cause delays. 🔑 Step 3: Track Keywords and Use Competitor Insights Once your audit is clean, you can track target keywords and layer in competitor data to strengthen your strategy. 1. From the left sidebar, click Keywords (URL: /research/keyword-researcher). 2. In the Keyword Researcher, enter your target keyword and run a search to see volume, difficulty, and SERP data. 3. To track a keyword, use the Add [keyword] to a keyword list or Rank Tracker link (or the Add to list button) in the Keyword Research/Rank Tracker results. Select the project and target location, then confirm. 4. To access Competitor Insights, look for the Competitors tab or panel within the Keyword Researcher or your project's keyword tracking view. Here you can: - See which competitors rank for the same keywords - Compare your ranking position against theirs - Identify keyword gaps — terms competitors rank for that you do not 5. Use the Import Keywords option if you have a list prepared outside the platform. Look for the Import button near the top of the keyword tracker, upload a CSV with one keyword per row, and map it to your project and location. Tip: After importing or adding keywords, allow up to 24 hours for ranking data to populate, especially for newly tracked terms. 📍 Step 4: Troubleshoot Missing Location Recommendations If one location is generating recommendations in OTTO SEO → All Sites (SEO Automation) but another is not, work through the following diagnostic steps. 1. Go to OTTO SEO → All Sites (SEO Automation) in the left sidebar and open the affected project. 2. Check that the location in question has been properly added to your project. Navigate to Project Settings → Locations and confirm the location appears and is marked as active. 3. Verify that tracked keywords are assigned to that specific location. A location with no tracked keywords will not generate recommendations. Go to your keyword tracker and filter by location to confirm keywords exist for it. Understanding auto-refresh and recommendation generation: - Recommendations are generated after a successful crawl and after keyword ranking data has been collected for the location. - If a location was added recently, it may need up to 24–48 hours before the system has enough data to produce recommendations. - Recommendations do not update in real time. The platform refreshes recommendation sets on a scheduled cycle tied to your crawl and rank-tracking intervals. - If a crawl completed but recommendations are still absent after 48 hours, try manually triggering a Refresh Recommendations action if available in the project dashboard, or rerun the audit for that project. Common reasons a location shows no recommendations: - No keywords are tracked for that location - The location was added after the last crawl completed and a new crawl has not run yet - The crawl for that project is still in progress - The target URL for that location was excluded by an existing exclusion rule 💬 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⚡ OTTO Crawl Limits for Bulk Page Additions

Overview When you add a large number of pages to OTTO at once, you may notice that only a portion of them appear in your crawl results immediately. This is expected behavior, not a bug. OTTO's crawl function has built-in processing limits for bulk additions, and full visibility across all newly added pages may not happen instantly. How OTTO Processes Newly Added Pages OTTO separates two distinct processes that customers often expect to happen simultaneously: - Page addition: The act of submitting new URLs to OTTO for tracking and optimization. - Crawl visibility: The appearance of those pages within OTTO's crawl results. Adding pages successfully does not mean they will all be visible in the crawl results right away. OTTO queues pages for analysis and processes them over time. When a large number of pages are submitted at once, only a portion may appear immediately — the rest are queued and will surface as OTTO continues to process them. Why Only Some Pages Are Appearing If you added a large batch of pages and only a fraction are showing in your crawl results, this reflects OTTO's processing behavior for bulk submissions. The pages that do not appear immediately are still queued and tracked — none are lost. They will become visible as OTTO works through the queue. This behavior is by design to maintain platform performance across all users. What You Can Do If you are waiting for pages to appear in OTTO after a bulk addition, the following steps can help manage your workflow: 1. Wait for processing to complete: Pages submitted in bulk will appear progressively as OTTO processes the queue. Check back periodically to see newly visible pages. 2. Submit smaller batches when possible: If you need certain pages to be processed sooner, consider submitting your highest-priority pages in a smaller, separate batch before submitting the rest. Smaller submissions are generally processed more quickly. 3. Confirm pages are queued: Verify within OTTO that your submitted URLs are listed and tracked, confirming they have been accepted into the system even if not yet fully visible in crawl results. 4. Contact support if pages remain missing: If pages have not appeared after an extended period and you believe there may be an issue, reach out to the support team with the specific URLs and the date you submitted them so the team can 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.

⭐ Add Review Stars Schema With Schema Creator

⭐ What Are Review Stars in Schema Markup? Review stars (also called star ratings) appear directly in Google search results beneath your page title. They are powered by structured data markup — specifically, Review or AggregateRating schema — that tells search engines about ratings associated with your content, product, or business. Adding this markup correctly can improve your click-through rate by making your listing stand out on the results page. 🗺️ Where to Find Schema Creator Schema Creator is a tool available within Search Atlas that allows you to build structured data for your pages without writing code manually. To locate Schema Creator, log in to your Search Atlas account and explore the available tools in your dashboard. If you are unsure where to find it, our support team can point you to the exact location for your account. 🛠️ How to Add Review Stars Schema Once you have located Schema Creator, you can use it to create a structured data block for review stars. The two main schema types relevant to star ratings are: - AggregateRating — used for an overall rating based on multiple reviews. This is the most common type for displaying star ratings in search results. - Review — used for a single individual review. To add review stars schema, open Schema Creator and select the appropriate schema type for your page. Fill in the relevant rating details as prompted by the tool, then copy the generated JSON-LD code and add it to the <head> section of your page's HTML, or via your CMS's schema or header script field. If you are not sure which schema type to choose or how to complete a particular field, contact our support team for guidance specific to your use case. ✅ Tips for Valid Review Stars Schema - Nest AggregateRating inside a parent schema — Google requires the rating to be attached to an entity such as Product, LocalBusiness, or Recipe. - Use real, accurate rating data — Google may penalise pages that display inflated or fabricated ratings. - Test your markup — after adding the schema to your page, use Google's Rich Results Test (search.google.com/test/rich-results) to confirm the structured data is valid and eligible for rich result display. - Keep ratings current — if your review count or score changes, update your schema accordingly to maintain accuracy. If you need further assistance, open 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 Crawler Resource Optimization for Dedicated Servers

🔍 Why the Crawler Can Overload a Server at 1 Page/Second Setting the crawler to 1 page per second does not mean your server processes only 1 lightweight request per second. Each crawl request triggers a chain of backend operations: DNS resolution, TCP handshake, HTML download, parsing, link extraction, redirect following, and database writes. On a typical server, this backend pipeline takes 200–800 ms per page depending on page complexity, server configuration, and whether caching is active. The actual CPU load is calculated as: CPU threads consumed ≈ Requests per second × Backend processing time (in seconds) For example, at 1 request/second with 600 ms average backend processing time, the crawler holds approximately 0.6 threads busy at all times. If you increase to 5 requests/second, that becomes 3 threads continuously occupied — consuming 75% of a 4-core server before accounting for your website, database, or other services running simultaneously. This is the root cause of excessive resource usage even at seemingly low crawl rates. ⚙️ How Caching Status Changes Resource Consumption Caching is the single biggest variable in crawler resource usage. When server-side caching (e.g., Redis, Varnish, or full-page caching plugins) is active and warm, backend processing time per page drops dramatically — often to 50–150 ms. When caching is cold or disabled, processing time rises to 400–900 ms per page, multiplying CPU load significantly. - Warm cache: Higher crawl speeds are safe; backend overhead is minimal. - Cold or no cache: Reduce crawl speed significantly; each request hits PHP, the database, and templating engines at full cost. - After a cache flush: Always lower crawl speed temporarily and allow the cache to rebuild before increasing again. 📋 Recommended Configuration Templates by Server Specs Use the table below as a starting point. Adjust based on your actual CPU load readings during a crawl (see Monitoring section below). 4-Core Server (16–32 GB RAM) - Max crawl speed (cache warm): 2–3 pages/second - Max crawl speed (cache cold): 1 page/second - Max concurrent connections: 2 - Crawl delay between requests: 400 ms minimum - Recommended crawl window: Off-peak hours only 8-Core Server (32–64 GB RAM) - Max crawl speed (cache warm): 5–7 pages/second - Max crawl speed (cache cold): 2–3 pages/second - Max concurrent connections: 4 - Crawl delay between requests: 150–200 ms - Recommended crawl window: Can run during business hours; monitor CPU for first 10 minutes 16-Core+ Server (64 GB+ RAM) - Max crawl speed (cache warm): 10–15 pages/second - Max crawl speed (cache cold): 5–6 pages/second - Max concurrent connections: 6–8 - Crawl delay between requests: 80–100 ms - Recommended crawl window: Flexible; maintain CPU headroom above 30% for other services Important: These are starting baselines. Always monitor live CPU and RAM usage during the first crawl session and scale back if utilization exceeds 70% sustained CPU on any core. 🛠️ How to Adjust Crawler Settings in Search Atlas 1. Log in to Search Atlas and navigate to Left sidebar → Site Explorer. 2. Select the project or domain you want to crawl. 3. Open the crawler configuration panel for that project. 4. Set Pages per second using the recommended values above for your server tier. 5. Set Concurrent connections to match the recommended value for your core count. 6. Enable Crawl delay and input the minimum millisecond value for your tier. 7. Save your configuration and start a test crawl on a small URL batch (50–100 pages) before running a full site crawl. 📊 Monitoring Tools and Metrics to Watch During and after a crawl, track the following server metrics to confirm your configuration is safe: - CPU utilization per core: Use top or htop on Linux. No individual core should sustain above 80% during a crawl. If it does, reduce pages/second immediately. - Load average: A 1-minute load average exceeding your core count (e.g., above 8.0 on an 8-core server) signals the server is queueing work faster than it can process it. - RAM usage: Watch for memory pressure above 85% used. Swap usage during a crawl indicates the server is under-resourced for your current settings. - Database query time: Slow query logs spiking during a crawl confirm the database is a bottleneck. Lower crawl speed and verify caching is routing repeated lookups away from the database. - Server response time: If your site's Time to First Byte (TTFB) rises above 1 second during crawling, the crawler is negatively impacting live visitors. Reduce speed immediately. ✅ Quick Troubleshooting Checklist - Verify caching is active and warm before starting a crawl at higher speeds. - Confirm no other resource-intensive processes (backups, database optimizations) are running simultaneously. - Start every new crawl configuration with a 50-page test batch before scaling to the full site. - After any server restart or cache flush, treat the server as "cold cache" and use the lower speed values until the cache rebuilds. - Review crawl logs for a high proportion of redirect chains or error responses — these increase backend processing time per request and require lower crawl speeds. 💬 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.

🚀 WordPress Domain Migration With SEO Preservation

🗺️ Overview Migrating a WordPress site to a new domain is one of the most SEO-sensitive tasks you can perform. Done correctly, you retain rankings, backlink equity, and indexed pages. This article walks you through the full process — from pre-migration data export to post-migration validation inside Search Atlas — and covers common project setup errors you may encounter along the way. 📦 Step 1: Export Your Current URL and Metadata Inventory Before touching anything on your site, capture a full snapshot of your existing SEO data. This gives you a baseline to compare against after migration and helps you catch any missing pages or broken metadata. 1. In Search Atlas, go to Left sidebar → Site Metrics → Pages. 2. Use the Filters and Columns options to display URL, page title, and meta description for all indexed pages. 3. Click History to save the current state as a reference point. 4. Export the data using the export option in the toolbar and save the file locally as your pre-migration inventory. Keep this file. You will re-run the same export after migration to compare old URLs against new ones and confirm no pages were lost. ⚙️ Step 2: Prepare Your WordPress Site for Migration Complete these steps inside WordPress and your hosting environment before changing any DNS settings. - Install your new domain on the destination server and verify it loads correctly before proceeding. - Clone your WordPress database and files to the new domain using a plugin such as Duplicator or All-in-One WP Migration, or via a manual export from phpMyAdmin. - Update Site URL settings: In WordPress, go to Settings → General and update both the WordPress Address and Site Address fields to the new domain. - Run a database search-and-replace to update all internal links and image paths. Use a tool such as Better Search Replace to replace every instance of the old domain with the new one in the database. - Test the new domain thoroughly — check pages, images, forms, and any third-party integrations — before going live. 🔗 Step 3: Set Up 301 Redirects on Your Old Domain 301 redirects tell search engines that your content has permanently moved. This is the single most important step for preserving SEO equity. 1. Add a wildcard 301 redirect in your old domain's .htaccess file (Apache) or server configuration (Nginx) that points every old URL to its exact equivalent on the new domain. 2. For example, olddomain.com/blog/post-slug should redirect to newdomain.com/blog/post-slug — not just to the homepage. 3. Test a sample of redirects using an HTTP status checker before submitting anything to Google. 4. Submit your new XML sitemap to Google Search Console under the new domain property. Also submit a Change of Address request in Google Search Console to accelerate the transition. 📊 Step 4: Add Your New Domain to Search Atlas and Validate Once the new domain is live and redirects are confirmed, add it as a project in Search Atlas and run a fresh analysis. 1. Go to Left sidebar → Site Metrics → All Sites and click Analyze. 2. Enter your new domain URL and start the analysis. 3. Once the project is saved, navigate to Site Metrics → Pages and export a new URL and metadata inventory. 4. Compare this export against your pre-migration snapshot to confirm all pages are present and metadata is intact. 5. Use Site Metrics → Position Changes to monitor keyword ranking changes over the following weeks. 🛠️ Fixing Common Project Setup Errors Some customers encounter validation errors when setting up a new project or connecting platform integrations. Here are the most common causes and fixes. - LinkedIn profile validation error: This typically occurs when the URL entered does not match the expected format. Make sure you are entering a full, public LinkedIn profile or company page URL (for example, https://www.linkedin.com/company/your-company-name). Personal profile URLs with custom slugs may not validate — try using the standard format. Also confirm the profile is set to public visibility. - Domain not resolving during project setup: If you add a domain before DNS propagation is complete, the platform may return an error. Wait 24–48 hours after a domain change before adding the new domain as a project. - Duplicate project warning: If the old domain was already saved as a project, the new domain will create a separate entry. This is expected behaviour. You can archive the old domain project once migration is complete by managing it under Site Metrics → All Sites. - Sitemap errors during crawl: If your sitemap was regenerated during migration, ensure the sitemap URL is correct and publicly accessible. Update the sitemap URL inside the project settings if needed. ✅ Post-Migration SEO Checklist - All old URLs return a 301 redirect to the correct new URL. - New XML sitemap is submitted to Google Search Console. - Change of Address request submitted in Google Search Console. - New domain added and analyzed in Search Atlas Site Metrics. - Pre- and post-migration URL inventories compared — no missing pages. - Keyword rankings monitored weekly for the first 60 days. - Backlinks pointing to the old domain are tracked and outreach prioritised for high-value links. 💬 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 Missing Solutions Page Links

🔍 What happened The Solutions dropdown may show Online Casinos, Sportsbooks, or Affiliate Sites as section anchors instead of links to their dedicated pages. An anchor such as #solutions-online-casino moves visitors to a section on the current page; it does not open /solutions/for-online-casinos/. 📄 Expected page links Each dropdown item should point to its corresponding page: - Online Casinos: /solutions/for-online-casinos/ - Sportsbooks: /solutions/for-sportsbooks/ - Affiliate Sites: /solutions/for-affiliate-sites/ ✅ Check the issue 1. Open the affected project in Website Studio. 2. Preview the website and open the Solutions dropdown. 3. Click each affected item and check the browser address bar. 4. Confirm whether the item opens the expected URL or only changes to an anchor beginning with #. 5. Check whether the three pages still appear in the project’s page list and whether their URLs return a valid page rather than a not-found response. 🛠️ Restore the correct links If the pages still exist, edit the Solutions navigation menu and replace each anchor target with the full relative page URL listed above. Save or publish the navigation changes, then test the links in a new private browser window. If a page is missing, unpublished, deleted, or has a different slug, restore or recreate the page using its intended URL before updating the menu. Avoid creating a duplicate page at a flat or alternate slug, because this can split internal links and create competing URLs. 🧪 Validate after publishing - Open all three URLs directly. - Confirm each page loads successfully and has the correct title and content. - Confirm the Solutions dropdown links to pages, not anchors. - Check that the pages are linked from the intended navigation and included in the sitemap when appropriate. - Clear any site or browser cache before retesting if the old anchor links remain visible. 💬 When to contact support If the pages cannot be restored, the navigation reverts to anchor links, or publishing creates duplicate or incorrect slugs, capture the project URL, affected page URLs, and a recording or screenshots of the behavior. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🌐 Fix Google's 'Not Globally Crawlable' Flag

🔍 What Does 'Not Globally Crawlable' Mean? When Google flags your site as not globally crawlable, it means Googlebot is being blocked from accessing your pages from one or more geographic regions. This flag appears in Google Search Console and signals that your site may not be indexed consistently worldwide. This flag has two possible root causes that require very different solutions. Understanding which applies to your situation will save you significant troubleshooting time. ⚠️ Two Root Causes — One Flag Before taking any action, it is important to distinguish between the two categories below: - Category 1 — Search Atlas / OTTO actionable: Issues related to how your site is configured within the Search Atlas ecosystem, such as incorrect crawl settings or OTTO directives that unintentionally restrict access. - Category 2 — External configuration (requires your developer or hosting provider): Issues that exist at the server, CDN, firewall, or hosting level and are entirely outside the scope of Search Atlas or OTTO. These require intervention from your technical team or hosting provider. The vast majority of not globally crawlable flags reported through Google Search Console fall into Category 2. Search Atlas does not control your server infrastructure, firewall rules, or CDN access policies. ✅ What Search Atlas Can Help You Check If you believe the issue may be related to your Search Atlas or OTTO configuration, verify the following before escalating externally: 1. Confirm that OTTO has not applied any unintended robots.txt directives that block Googlebot. Review your active OTTO tasks and look for any robots.txt changes that may have been deployed. 2. Check that no noindex or nofollow tags have been pushed site-wide by mistake through OTTO optimisations. 3. Ensure your sitemap submitted in Google Search Console is current and reflects the correct URLs for your site. If none of the above apply, or if OTTO has not made changes to your robots.txt or meta directives, the root cause is almost certainly external to Search Atlas. 🛠️ External Causes That Require Developer or Hosting Intervention The following issues are outside the scope of Search Atlas and OTTO. Your developer or hosting provider must resolve them: - Geo-blocking or IP filtering: Your server, firewall, or security software is blocking requests from certain countries or IP ranges, including Google's crawl infrastructure. - CDN misconfiguration: Your content delivery network (for example, Cloudflare, Fastly, or AWS CloudFront) may be restricting access based on region or flagging Googlebot as suspicious traffic. - Hosting provider restrictions: Some hosting plans restrict traffic from outside specific regions by default. Your hosting provider's control panel or support team can confirm and adjust this. - DDoS protection or bot mitigation tools: Security services that block automated bots may inadvertently block Googlebot. Your developer needs to whitelist Google's verified crawlers in your security settings. - Server-side redirects or authentication walls: If your server returns different responses based on the visitor's geographic location, Google may be served a blocked or redirect response in certain regions. 📋 How to Diagnose the Issue Quickly Follow these steps to identify whether the problem is internal or external: 1. Open Google Search Console and navigate to Settings → Crawl Stats. Look for errors tied to specific response codes (403, 429, or connection timeouts) that indicate server-level blocking. 2. Use Google's URL Inspection Tool inside Search Console to test a sample URL. If Google reports it cannot reach the page, the block is at the server or network level. 3. Use a third-party tool such as GeoPerf or Uptrends to test your site's availability from multiple global locations. If the site fails to load from certain regions, confirm a server or CDN-level block is in place. 4. Ask your hosting provider or developer to review your firewall logs for blocked requests from Googlebot IP ranges, which are published in Google's official documentation. 🚀 Recommended Next Steps Based on Your Situation - If OTTO or Search Atlas changes are the suspected cause: Review your OTTO task history and revert any robots.txt or meta tag changes. Contact our support team via the chat widget for guided assistance. - If the issue is external (most common scenario): Share the diagnostic information from Google Search Console and your geo-availability test results with your developer or hosting provider. Ask them specifically to review firewall rules, CDN geo-restrictions, and bot mitigation settings. - If you are unsure which category applies: Start with the OTTO review steps above, then run the URL Inspection Tool in Google Search Console. If Google still cannot reach the page and OTTO has made no relevant changes, escalate externally. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛡️ WordPress Malware Response and Site Remediation

🔍 Overview If you've noticed a suspicious script, unexpected redirect, or unfamiliar code appearing on your WordPress site — particularly in the footer, header, or theme files — this article will help you understand what's happening and how to respond. Search Atlas and the OTTO SEO plugin do not inject unauthorized scripts or malicious code of any kind. If suspicious code has appeared on your site, the cause is almost certainly a compromised WordPress installation, theme, plugin, or hosting account. ⚠️ Is the Suspicious Script Related to Search Atlas or OTTO? No. The OTTO SEO plugin communicates exclusively with Search Atlas servers to manage SEO tasks such as schema markup, internal linking, and on-page optimizations. It does not modify your site's footer with third-party scripts, inject advertising code, or communicate with any domain outside of Search Atlas infrastructure. If you see an unfamiliar script in your footer or elsewhere, the most likely causes are: - A compromised WordPress plugin or theme (including nulled or outdated software) - Unauthorized access to your WordPress admin account or hosting control panel - A vulnerability in your WordPress core installation - Malicious code injected through your hosting server or database 🛠️ Immediate Steps to Take 1. Take your site offline or enable maintenance mode to prevent visitors from being exposed to malicious content while you investigate. 2. Change all passwords immediately: WordPress admin accounts, FTP/SFTP credentials, hosting control panel, and your database password. 3. Revoke and regenerate API keys for any third-party services connected to your site, including your Search Atlas API key if it was stored in plain text anywhere. 4. Notify your hosting provider. Most hosts have a security team that can scan your server environment and isolate the infection at the server level. 🔬 How to Identify the Malicious Code Use the following steps to locate and remove the suspicious code: 1. Scan with a WordPress security plugin. Install and run a reputable scanner such as Wordfence, Sucuri Security, or MalCare. These tools compare your core files against known-clean versions and flag anomalies. 2. Check recently modified files. Via FTP or your host's file manager, sort files by last-modified date. Malware often modifies wp-config.php, functions.php, index.php, or .htaccess. 3. Inspect your database. Use phpMyAdmin to search for suspicious strings such as eval(base64_decode, <script src= pointing to unknown domains, or document.write in your wp_options or wp_posts tables. 4. Review installed plugins and themes. Deactivate and delete any plugins or themes you do not recognize, any that have not been updated in over a year, or any obtained from unofficial sources. 🧹 Cleaning and Restoring Your Site 1. Restore from a clean backup if you have one dated before the infection. This is the fastest and most reliable remediation method. Confirm the backup is clean before restoring. 2. Reinstall WordPress core files. From your WordPress dashboard, go to Dashboard → Updates and click Re-install version X.X.X. This overwrites core files without affecting your content. 3. Replace theme and plugin files with fresh downloads from wordpress.org or the original developer. Do not reuse existing files that may be infected. 4. Clean your database manually by removing any injected scripts found during your inspection. 5. Implement a Web Application Firewall (WAF) such as Cloudflare or Sucuri to block future intrusion attempts. ✅ After Cleanup: Hardening Your WordPress Site Once your site is clean, take these steps to reduce the risk of reinfection: - Keep WordPress core, all themes, and all plugins updated at all times. - Use strong, unique passwords and enable two-factor authentication (2FA) on your WordPress admin account. - Limit login attempts using a plugin or your WAF rules. - Remove unused themes and plugins entirely — deactivated plugins can still be exploited. - Set correct file permissions: 644 for files and 755 for directories. - Move wp-config.php one directory above your WordPress root if your host supports it. - Schedule regular automated backups stored off-server (e.g., Amazon S3, Google Drive). 🔗 Verifying OTTO Is Working Correctly After Remediation After cleaning your site, verify the OTTO SEO plugin is functioning as expected by navigating to OTTO SEO → All Sites (SEO Automation Projects) in the left sidebar of your Search Atlas dashboard. Confirm that your site is connected, tasks are running normally, and no error messages appear. If OTTO was deactivated during cleanup, simply reactivate it from your WordPress plugin manager — no reconfiguration is needed as long as your API key is intact. 💬 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 robots.txt Crawl-Delay Directive

🔍 Why This Error Appears in Search Atlas When Search Atlas crawls your site, it flags a crawl-delay directive in your robots.txt file as a critical error. This directive instructs search engine bots to pause between requests, which can significantly slow down how quickly Google and other search engines index your pages. If your store runs on Shopify, you have likely already discovered that you cannot simply open and edit your robots.txt file the way you would on a self-hosted site. This is expected behavior — it is a platform-level restriction, not a problem with your account or Search Atlas. 🛍️ Why Shopify Locks Your robots.txt File Shopify automatically generates a robots.txt file for every store. On most plans, this file is managed by Shopify's infrastructure and is not directly editable through the Shopify admin panel or theme editor by default. The crawl-delay directive you see is typically injected by Shopify itself or by a third-party app installed on your store. Because of this, standard advice such as "open your robots.txt file and delete the line" does not apply to Shopify stores. You need to use one of the platform-specific methods described below. ✅ Method 1: Check for Apps Injecting the Directive The most common cause of a crawl-delay directive on Shopify is a third-party SEO or security app that modifies your robots.txt output. Follow these steps to identify and remove the source: 1. Log in to your Shopify Admin panel. 2. Go to Apps in the left sidebar. 3. Review any installed SEO, site speed, or security apps such as SEO Manager, Plug in SEO, or bot-protection tools. 4. Open each relevant app's settings and look for a robots.txt or crawl settings section. 5. If you find a crawl-delay setting, disable it or set the value to 0 and save. 6. Wait 24–48 hours, then re-run a crawl in Search Atlas to confirm the error is resolved. If you are unsure which app is responsible, temporarily disable SEO-related apps one at a time and check your live robots.txt file at yourdomain.com/robots.txt after each change to identify the source. ✅ Method 2: Use a Custom robots.txt Template (Shopify 2.0 Themes) If your store uses a Shopify Online Store 2.0 theme, Shopify allows you to override the default robots.txt file using a Liquid template. This method gives you full control over the file's content. 1. In your Shopify Admin, go to Online Store → Themes. 2. Next to your active theme, click Actions → Edit code. 3. In the left file panel, look for a folder called Templates. 4. If a file named robots.txt.liquid already exists, click it to open it. If it does not exist, click Add a new template, select robots.txt from the dropdown, and click Create template. 5. Review the template content and remove any line that contains crawl-delay. 6. Click Save. 7. Visit yourdomain.com/robots.txt to confirm the directive is no longer present. Important: When creating a custom robots.txt.liquid template, Shopify replaces its automatically generated file entirely with your template. Make sure the template retains all necessary Disallow and Sitemap directives from the original. You can copy the current content of your live robots.txt as a starting point before making edits. ✅ Method 3: Contact Shopify Support If your theme is not a 2.0 theme, the robots.txt.liquid template option is unavailable, and no installed app appears to be the source of the directive, the crawl-delay may be hard-coded by Shopify at the infrastructure level. In this case, direct editing is not possible without Shopify's involvement. Contact Shopify Support directly and provide the following information: - Your store URL and the current content of your robots.txt file. - The specific crawl-delay line you need removed. - A note that the directive is causing indexation issues flagged by your SEO tooling. Shopify support can advise whether an upgrade to a 2.0-compatible theme or a platform-level change is required. 📊 Verifying the Fix in Search Atlas After applying any of the methods above, confirm the error has been resolved in the Search Atlas dashboard: 1. In the left sidebar, navigate to OTTO SEO V3. 2. Open your active project and locate the site audit or technical SEO section. 3. Trigger a new crawl of your site. 4. Once the crawl completes, confirm the crawl-delay critical error no longer appears in your issue list. If the error persists after the crawl, revisit your robots.txt file directly at yourdomain.com/robots.txt to verify the directive has been fully removed before re-crawling. 💬 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 Broken Links Using Atlas Agent

🧭 What This Article Covers Atlas Agent can help you identify and fix broken links on your website through the Site Auditor tool. However, the steps to access Site Auditor may look different depending on your plan tier, user role, and current UI configuration. This article walks you through every scenario so you can get started without hitting a dead end. ✅ Before You Begin: Requirements Checklist Make sure the following conditions are met before following the steps below: - Plan tier: Site Auditor is available on Pro plans and above. If you are on a Starter plan, you will not see this tool in your sidebar. - User role: You must have Admin permissions to run a site audit and trigger Atlas Agent automations. Viewer accounts cannot initiate crawls or fixes. - Project set up: You must have at least one active project with a connected domain before Site Auditor can crawl your site. If you are unsure about your plan or role, navigate to Avatar (top-right) → Billing → Plans & Top-ups (Change Plan) to check your plan, or ask your workspace Admin to confirm your permissions. 🗺️ How to Navigate to Site Auditor Depending on your UI version, Site Auditor may appear in one of two locations: - Standard sidebar layout: In the left-hand sidebar, look for the Site Auditor option under the SEO Tools section. - Condensed or icon-only sidebar: The sidebar may be collapsed. Click the expand arrow on the left edge of the screen to reveal full menu labels, then look for Site Auditor under SEO Tools. - Top-navigation layout (some Enterprise accounts): Navigate to OTTO SEO → Site Audit → Overview (Website Overview). If you do not see Site Auditor in any of these locations, your plan may not include it. See the section below on plan access for next steps. 🚀 Running a Crawl and Using Atlas Agent to Fix Broken Links 1. Open OTTO SEO → Site Audit → Overview (Website Overview) and select the project you want to audit from the project dropdown at the top of the page. 2. Click Recrawl Site. The crawl may take a few minutes depending on your site size. 3. Once the crawl is complete, go to the Issues tab and filter by Broken Links or look for the 4xx Errors category in the issues list. 4. Select one or more broken link issues by checking the boxes next to them. 5. Click the Fix with Atlas Agent button that appears in the action bar above the issue list. 6. Atlas Agent will open a task panel on the right side of the screen. Review the suggested fixes — these may include redirect recommendations, link replacements, or removal suggestions. 7. Approve individual fixes or click Apply All to let Atlas Agent implement the recommended changes automatically. 8. After fixes are applied, re-run a crawl to confirm the broken links have been resolved. 👥 Guidance for Different User Roles Admin users have full access to Site Auditor, all crawl settings, and Atlas Agent automation. No additional steps are needed. Editor users can run crawls and use Atlas Agent to apply fixes, but cannot change the connected domain or billing settings. If a fix requires domain-level changes, flag it to your Admin. Viewer users can see audit results but cannot run new crawls or use Atlas Agent. If you need to take action on broken links, contact your workspace Admin to upgrade your role. 📋 Plan Tier Availability - Starter: Site Auditor is not included. Upgrade to Pro or higher to access this feature. - Pro: Full Site Auditor access with Atlas Agent automation for broken link fixes. - Agency and Enterprise: All Pro features plus multi-project crawls, advanced filtering, and priority processing for large sites. To upgrade your plan, go to Avatar (top-right) → Billing → Plans & Top-ups (Change Plan) and select a plan that includes Site Auditor. 🔧 Common Access Issues and Fixes - Site Auditor is missing from the sidebar: Your plan does not include this feature, or your role is set to Viewer. Check your plan and permissions in Account Settings. - The Fix with Atlas Agent button does not appear: Make sure you have selected at least one issue using the checkboxes. The button only appears when one or more issues are selected. - Crawl is stuck or shows an error: Verify your domain is correctly connected under Project Settings. If the domain requires authentication, make sure crawl credentials are saved. - Atlas Agent suggestions are greyed out: This can happen if your session has timed out. Refresh the page and re-select your issues. 💬 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.

🌐 Migrating Your Search Atlas Project to a New Domain

🔑 The Most Important Thing to Know First Search Atlas projects are locked to the domain they were created with. There is no built-in migration tool to transfer an existing project — including its OTTO recommendations, audit history, and tracked data — to a new domain. If your website URL has changed, you must choose one of two supported paths described below. 📋 Your Two Options at a Glance - Option 1 — Create a new project (recommended): Start fresh under your new domain. You get a clean slate with accurate data, but you lose historical audit results and previously applied OTTO recommendations. - Option 2 — Manually transfer OTTO recommendations: Keep your old project open as a reference and re-apply key recommendations inside a new project for your new domain. This takes more effort but helps preserve institutional SEO knowledge from your previous setup. 🚀 Option 1: Create a New Project (Recommended) This is the fastest way to get accurate SEO data for your new domain. 1. In the left sidebar, go to Home → Classic. 2. Click Create a Project (Home | searchatlas.com). 3. Enter your new domain URL and complete the project setup wizard. 4. Once the project is created, launch a Site Audit to detect technical issues on the new site. 5. Activate OTTO for the new project and review the fresh recommendations generated for your new domain. 6. Update your Brand Vault with any new brand details, target keywords, and business information relevant to the rebuilt site. 7. Reconnect any integrations (such as Google Search Console) to the new domain inside the project settings. Trade-off: All historical data, previously applied fixes, and OTTO deployment history from your old project will not carry over. Your old project will remain in your account — do not delete it until you have finished referencing it. 🔄 Option 2: Manually Transfer OTTO Recommendations Use this approach if your old site had extensive OTTO work that you want to preserve as a reference during your new build. 1. Open your old project in Search Atlas and navigate to OTTO SEO → All Sites (SEO Automation). 2. Export or document the recommendations that were applied — take note of meta titles, descriptions, heading structures, schema types, internal linking patterns, and any other fixes that were deployed. 3. Follow all steps in Option 1 to create a new project for your new domain. 4. Inside the new project, open OTTO and manually implement the equivalent recommendations where they still apply to the new site's structure. 5. Re-run a site audit on the new project to confirm the changes have been applied correctly and to catch any new issues introduced during the rebuild. Trade-off: This process is time-intensive and requires judgment about which old recommendations are still relevant after a rebuild. Not all previous fixes will apply if the site structure or content has significantly changed. ✅ Best Practices for SEO Continuity After a Domain Change - Set up 301 redirects from every old URL to its equivalent new URL as soon as the new site goes live. This is the single most important step for preserving search rankings and passing link equity. - Update Google Search Console by adding and verifying your new domain as a separate property, then submit a new sitemap. - Monitor crawl errors in your new Search Atlas project after the site is indexed to catch broken links or redirect issues early. - Do not delete your old Search Atlas project immediately. Keep it available for at least 60–90 days as a reference for historical keyword rankings and previously applied recommendations. - Re-target keywords in your new project — if the site structure changed during the rebuild, take this opportunity to review and refine your keyword strategy rather than simply copying the old one. - Update internal links throughout the new site to point to the correct new URLs rather than old ones, and verify them inside your site audit. ❓ Frequently Asked Questions - Can I rename or re-point my existing project to the new domain? No. Domain changes at the project level are not supported. A new project must be created. - Will my old project affect billing? Yes, if your plan has a project limit, your old project counts toward that limit until you delete it. Review your plan before creating the new project. - What happens to keyword rank tracking? Rank tracking history is tied to the old project. You will need to add your target keywords again in the new project to begin fresh tracking for the new domain. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🕷️ Optimise Crawler Settings for Your Server

🔍 Understanding How the Crawler Uses Server Resources The Search Atlas crawler is designed to be thorough and accurate, which means it performs multiple operations per page visit — fetching HTML, resolving redirects, analysing on-page elements, and storing results. Even when the crawl speed is set to 1 page per second, these parallel background processes can place a noticeable load on your server, especially on resource-constrained hosting environments. The key thing to understand is that crawl speed (pages per second) is not the only factor that determines server load. Concurrent connections, page complexity, server response times, and the size of your site all contribute to total resource consumption during a crawl. ⚙️ What Affects Server Resource Usage - Concurrent connections: Even at 1 page per second, the crawler may open multiple simultaneous connections to fetch resources like images, scripts, and stylesheets referenced on each page. - Page complexity: Pages with many internal links, large HTML payloads, or heavy JavaScript increase the processing work required per page. - Server response time: A slow server causes connections to remain open longer, stacking up alongside new requests and increasing peak load. - Redirect chains: Each redirect adds an extra request, multiplying the total number of HTTP calls the crawler makes. - Site size: Larger sites mean the cumulative effect of even a conservative crawl rate lasts much longer, sustaining elevated resource usage over an extended period. 🖥️ Recommended Configuration for an 8-Core Dedicated Server An 8-core dedicated server has more headroom than shared hosting, but it is still important to configure the crawler thoughtfully to avoid impacting live site performance for real visitors. Follow these guidelines: 1. Set crawl speed to 2–4 pages per second as a starting point. An 8-core server can generally handle this comfortably, but monitor CPU and memory usage during the first crawl to confirm. 2. Schedule crawls during low-traffic periods — typically late night or early morning in your visitors' primary time zone. This ensures the crawler competes with as little live traffic as possible. 3. Limit concurrent connections if your crawler settings expose this option. A value of 4–6 concurrent connections is a sensible ceiling for most dedicated servers. 4. Exclude unnecessary URLs from the crawl scope. Use the URL exclusion or path filtering settings to skip admin paths, media upload directories, and any dynamically generated pages that do not need SEO analysis. 5. Pause and resume crawls if you notice performance degradation. You do not need to restart from the beginning — the crawler can resume where it left off. 6. Review your server's error logs after the first crawl. A spike in 503 (Service Unavailable) or 429 (Too Many Requests) responses is a reliable signal that you need to reduce speed or concurrency further. 💡 Tips to Reduce Crawl Impact Without Sacrificing Coverage - Use a crawl budget wisely: Prioritise crawling your most important URLs — product pages, blog posts, and landing pages — and exclude low-value pages like tag archives, search result pages, and session-ID URLs. - Enable caching on your server: A properly configured server-side cache (e.g. Redis, Varnish, or a CDN) dramatically reduces the processing overhead of each crawler request because the server returns a cached response instead of regenerating the page. - Check your robots.txt: Ensure the Search Atlas crawler is not blocked from pages you want crawled, and that it is blocked from areas you do not — such as /wp-admin/ or /checkout/. - Keep the crawl scope focused: If you are running a targeted audit, crawl a specific subdirectory rather than the entire domain to reduce total requests. 🚀 Monitoring Resource Usage During a Crawl While a crawl is running, use your server's monitoring tools (such as htop, Netdata, or your hosting control panel's resource graphs) to watch CPU load, RAM usage, and active connections in real time. A healthy crawl on an 8-core dedicated server should keep average CPU usage below 60–70%. If you consistently see CPU peaking above 90% or RAM approaching its limit, reduce the crawl speed setting and restart the crawl. If your hosting provider enforces rate limits or automatically throttles connections from a single IP, contact them to whitelist the Search Atlas crawler IP ranges so legitimate crawl traffic is not misidentified as an attack. 🛠️ Need Further 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.

🔍 Filter Site Audit Results to Non-Compliant Pages Only

🧭 Overview Site Audit surfaces every page the crawler evaluates — including pages that are fully compliant. By default, the results table shows all crawled URLs, so you may see a mix of passing and failing pages. This article explains how to filter the view to show only non-compliant pages and clarifies a common question about URLs that appear with /2, /3, or /4 suffixes. 🚦 Why Compliant Pages Appear in Your Results Site Audit is designed to give you a complete picture of your site's health. Every crawled URL — whether it passes or fails a check — is included in the results table. This means compliant pages will appear alongside non-compliant ones unless you actively apply filters to narrow the view. This is expected behavior, not a bug. ✅ How to Show Only Non-Compliant Pages Use the built-in issue filters in Site Audit to isolate pages that have at least one detected problem. Follow these steps: 1. Open Site Audit from the left sidebar under OTTO SEO (OTTO SEO → Site Audit). 2. Select the audit project you want to review. 3. In the results table, locate the Filter bar at the top of the page list. 4. Click the filter dropdown and select the specific issue type you want to focus on — for example, Missing Meta Description, Broken Links, or Missing H1. 5. The table will refresh to show only URLs that have that issue flagged. Pages with no issues for that check will be excluded from the view. 6. To see all non-compliant pages across multiple issue types, apply additional filters one at a time or use the issue category panels to drill into each check separately. Important: The Create Segment and Manage Columns options are not designed to filter by compliance status. Using them for this purpose will not produce the results you need. Stick to the Filter bar and issue category panels for accurate filtering. 📋 Reviewing Issues by Category A faster way to focus on non-compliant pages is to navigate by issue category rather than the full URL list: 1. From your audit project, scroll to the Issues section or click any issue category tile on the audit summary screen. 2. Each category — such as Indexability, On-Page SEO, or Performance — shows only the pages affected by that issue group. 3. Click into a specific issue to see the exact list of non-compliant URLs for that check. This approach is the most reliable way to work through non-compliant pages systematically without manually filtering the full results table. 🔢 Understanding /2, /3, /4 URL Suffixes in Site Audit You may notice that a single page on your site appears in Site Audit results with multiple URL variants, such as: - example.com/my-page - example.com/my-page/2 - example.com/my-page/3 These suffixes are not pagination issues, duplicate content errors, or problems introduced by a platform change. They reflect a known behavior of the Site Audit crawler. Here is what causes them: - When a page contains paginated content blocks — such as comment sections, product listings, or posts that load across multiple internal pages — the crawler follows each paginated segment as a separate URL. - The /2, /3, and /4 suffixes represent those paginated segments as the crawler discovers and indexes them. - This is consistent with how search engines also crawl paginated content, so the behavior reflects real URL structures on your site rather than a platform error. If you see these suffixes for a page that you do not believe has paginated content, check whether your CMS or theme is generating pagination parameters automatically — for example, through comment pagination settings in WordPress. ⚠️ What These Suffixes Are Not - They are not caused by a Search Atlas platform update or bug. - They are not duplicate URL errors that require canonical tags to fix (though adding canonicals to paginated segments is still a best practice if the content is thin). - They are not a sign that the crawler is misidentifying your pages. 🛠️ Recommended Next Steps - Use the issue category panels in Site Audit to work through non-compliant pages efficiently. - Apply the Filter bar to isolate specific issue types when you need a focused URL list. - If /2, /3, /4 URLs are appearing unexpectedly, review your CMS pagination settings and consider adding rel=canonical tags pointing to the root URL of the page. - Re-run the audit after making changes to confirm that flagged issues are resolved. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🩺 Understanding Healthy Pages in Site Health Audit

📋 What Is the Healthy Pages Count? The healthy pages metric in the Site Health Audit shows the number of pages on your site that have no detected SEO issues. A page is counted as healthy only when it passes all checks performed during the audit — including crawlability, indexability, metadata, response codes, and more. If you are seeing a number that feels lower than expected, this is almost always because some pages have at least one issue flagged against them, which moves them out of the healthy count — even if the issue is minor. 🔍 Why Is Your Healthy Page Count Low? Several common reasons cause the healthy pages number to be lower than the total number of pages crawled: - Pages with warnings: Pages flagged with warnings — such as missing meta descriptions, slow load times, or thin content — are not counted as fully healthy. - Pages with errors: Any page returning a 4xx or 5xx status code, or blocked by robots.txt, is excluded from the healthy count. - Redirect chains: Pages involved in redirect chains or loops are flagged and removed from the healthy count. - Noindex tags: Pages carrying a noindex directive may be excluded from the healthy count depending on your audit configuration. - Incomplete crawl: If the audit crawled only a portion of your site — due to crawl limits, login-gated pages, or crawl depth settings — the total pages discovered may be lower than expected, which directly affects how many can be counted as healthy. - Recently added pages: Pages added after the last audit run will not appear until you refresh the audit. 🗺️ How to Identify Which Pages Are Not Healthy 1. Navigate to the Site Health Audit from the left sidebar. 2. Open your site's audit report and locate the Issues or Pages tab. 3. Filter the page list by status — look for pages marked as Errors, Warnings, or Notices. 4. Click into any flagged page to see the specific issues preventing it from being counted as healthy. 5. Prioritise fixing errors first, as these have the greatest impact on your healthy page count and overall SEO performance. 🔄 How to Refresh or Re-run Your Audit Your healthy page count reflects the state of your site at the time of the last audit crawl. If you have recently fixed issues or published new pages, re-run the audit to get an updated count: 1. Go to OTTO SEO → Site Audit → Overview (Website Overview). 2. Select your site from the list. 3. Click Recrawl Site to trigger a new audit. 4. Wait for the crawl to complete — crawl time varies based on site size. 5. Review the updated healthy pages figure once the audit finishes. 📊 How to Improve Your Healthy Pages Count Increasing your healthy pages count means resolving the issues flagged on affected pages. Here is a recommended order of priority: - Fix errors first: Broken links, server errors, and blocked pages have the highest impact. Resolve these before moving to warnings. - Address missing metadata: Add or complete meta titles and meta descriptions on all pages that are missing them. - Resolve duplicate content: Use canonical tags to consolidate duplicate or near-duplicate pages. - Improve page speed: Pages flagged for slow load times can be optimised through image compression, caching, and script management. - Clear redirect issues: Audit and simplify any redirect chains so pages resolve cleanly in a single hop. After resolving a batch of issues, re-run the audit to confirm the pages have moved into the healthy count. ❓ Frequently Asked Questions Does a low healthy page count mean my site is performing badly? Not necessarily. A low count highlights opportunities for improvement. Even sites with strong organic traffic often have a proportion of pages with minor issues. Focus on fixing errors before warnings. Can the healthy page count ever exceed the total crawled pages? No. The healthy count is always a subset of the total crawled pages. If the numbers look inconsistent, try re-running the audit to ensure the data is current. Why does the crawled page total seem lower than my actual site? Crawl limits, nofollow links, login-required pages, and crawl depth settings can all restrict which pages are discovered. Review your audit settings to ensure the crawler has access to all relevant sections of your site. 💬 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.

🔒 SSL Certificates and 404 Redirects Explained

🔍 Overview Two of the most common questions we receive about the Search Atlas redirections and hosting features are: Can Search Atlas enable a wildcard SSL certificate for my site? and Can Search Atlas automatically redirect 404 pages to the homepage? This article explains the current state of both features and how to get the best results today. 🔐 Wildcard SSL Certificates A wildcard SSL certificate secures a root domain and all of its subdomains under a single certificate (for example, *.yourdomain.com). This eliminates the need to issue and renew separate certificates for each subdomain. Here is what you need to know about wildcard SSL in Search Atlas: - Search Atlas infrastructure: Our own platform already uses consolidated wildcard TLS certificates across *.searchatlas.com subdomains, ensuring secure and reliable connections to all platform services. - Your site's SSL: Wildcard SSL for customer-owned domains is managed at the hosting or DNS provider level — for example, through Cloudflare, your web host, or a certificate authority such as Let's Encrypt. Search Atlas does not issue or manage SSL certificates for external domains. - What to do: If you need a wildcard SSL certificate for your own domain, contact your hosting provider or DNS service. Most modern hosts offer free wildcard certificates via Let's Encrypt or similar services. ↩️ Redirecting 404 Pages to the Homepage A 404-to-homepage redirect automatically sends visitors who land on a broken or non-existent URL to your homepage instead of seeing an error page. This is a common request for protecting user experience and preserving link equity. The Search Atlas Redirections module (available through the WordPress plugin) allows you to create and manage redirect rules for your site. Here is how to set up a catch-all redirect for 404 errors: 1. Log in to your WordPress dashboard and navigate to the Search Atlas plugin. 2. Open Settings from the Search Atlas plugin menu and locate the Redirection toggle in the SEO Controls area. 3. Click Add New Redirect. 4. In the Source URL field, enter the pattern for the URLs you want to catch. For a broad catch-all, use a regex pattern that matches invalid URL paths on your site. 5. Set the Destination URL to your homepage (for example, https://yourdomain.com/). 6. Choose 301 (permanent) or 302 (temporary) as the redirect type, depending on your needs. A 301 is recommended for SEO purposes when the content is permanently gone. 7. Save the rule and test it by visiting an invalid URL on your site to confirm the redirect works as expected. Important: Use catch-all redirect rules with care. Redirecting every 404 to the homepage with a 301 can dilute your site's crawl budget and may send mixed signals to search engines about your site structure. Consider whether a custom 404 page or targeted redirects to relevant content would be a better fit for your situation. ⚠️ Known Limitations to Be Aware Of We are committed to transparency about current platform limitations. Please keep the following in mind when working with the Redirections module: - Wildcard redirect patterns: Full wildcard pattern matching (using * as a pattern type) is not currently supported in the Redirections module due to a technical constraint in how redirect pattern types are stored. Our team is aware of this limitation and is actively working on a resolution. - Regex patterns: As an alternative to wildcard patterns, you can use regular expressions (regex) in the Source URL field to match a broad range of URL patterns. This gives you flexible control over which URLs are caught by a redirect rule. - Testing redirects: Always test new redirect rules on a staging environment before applying them to your live site, especially when using broad patterns. ✅ Quick Reference: What Search Atlas Handles vs. Your Hosting Provider - Search Atlas handles: Redirect rules via the Redirections module, HTTP-to-HTTPS redirects for platform URLs, and secure TLS for all Search Atlas services. - Your hosting provider handles: SSL/TLS certificates for your own domain and subdomains, server-level redirect configurations (such as .htaccess or Nginx rules), and wildcard certificate issuance and renewal. 💬 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.

🔍 Filter Site Audit Results to Non-Compliant Pages

🗺️ Overview By default, Site Audit displays all crawled pages — both compliant and non-compliant. This article explains how to filter the results so you see only the pages that need attention, and clarifies why you may notice duplicate URLs with suffixes such as /2, /3, or /4 appearing for a single page. ⚙️ How to Filter for Non-Compliant Pages Only Follow these steps to narrow Site Audit results down to pages that have at least one issue: 1. In the left sidebar, navigate to OTTO SEO → All Sites (SEO Automation) (URL: /seo-automation-v3). 2. Open your project and go to the Site Audit section. 3. Locate the Compliance or Status filter at the top of the results table. 4. Select Non-Compliant (or Issues Found, depending on your view) from the filter dropdown. 5. Click Apply. The table will refresh and display only pages that have one or more unresolved issues. You can combine this filter with other filters — such as issue type, priority level, or page category — to further narrow your focus and prioritise fixes efficiently. 📊 Understanding the Compliance Status Labels Site Audit assigns one of the following statuses to each crawled page: - Compliant — The page meets all checked SEO criteria. No action is required. - Non-Compliant — The page has one or more SEO issues that need to be resolved. - Not Applicable — The audit rule does not apply to this page type (e.g., a rule about product schema on a blog post). Filtering by Non-Compliant removes compliant and not-applicable pages from view, so your team can focus exclusively on pages that require work. 🔗 Why Duplicate URLs with /2, /3, /4 Appear If you see the same page URL listed multiple times with numeric suffixes — for example /about, /about/2, /about/3 — this is almost always caused by one of the following: - Pagination: Your CMS or theme generates paginated versions of a page (common with comment sections, long archive pages, or product listings). Each paginated variant is treated as a separate URL by the crawler. - Duplicate crawl paths: Internal links on your site point to the same content using different URL structures, causing the crawler to log each variant individually. - Plugin or theme behaviour: Certain WordPress plugins or themes append page numbers to URLs even when there is no additional content to paginate. These duplicate URLs are not a bug in Site Audit — the crawler is accurately reporting what it finds. However, they can inflate your page count and make it harder to spot genuine issues. Here is how to address them: 1. Add canonical tags to paginated URLs pointing back to the primary (page 1) URL, signalling to search engines which version is authoritative. 2. Implement rel="next" / rel="prev" markup if the pagination contains genuinely distinct content. 3. Disable unnecessary pagination in your CMS settings or plugin configuration if the extra pages serve no content purpose. 4. Use the URL filter in Site Audit to exclude suffix patterns (e.g., filter out URLs containing /2, /3) while you investigate, keeping your working view clean. 💡 Tips for Working Through Audit Results Efficiently - Sort by Issue Count (descending) after applying the Non-Compliant filter to tackle the most problematic pages first. - Use the Issue Type filter alongside the compliance filter to address one category of problem at a time (e.g., all missing meta descriptions). - Re-run the audit after making fixes to confirm pages move to Compliant status. - Export the filtered results using the Export to Docs button (via OTTO SEO → Site Audit → Overview (Website Overview)) to share a prioritised fix list with your development or content team. 🛠️ Still Need Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. Additional Notes Important: The Create Segment and Manage Columns options are not designed to filter by compliance status. Using them for this purpose will not produce the results you need. Stick to the Filter bar and issue category panels for accurate filtering.

🔎 How to Find Missing Brand Fields

This article shows how to review Brand Vault, identify incomplete fields, and confirm your updates were saved. 📍 Where to Find It Open OTTO SEO from the left sidebar, select Overview, then open Brand Vault. 🛠️ Step-by-Step 1. Review each section in Brand Vault from top to bottom. 2. Identify fields that are blank, show placeholder text, or contain outdated information. 3. Enter the requested brand information in every incomplete field. 4. Check the remaining sections for additional empty or incomplete fields before leaving the page. 5. Save your updates using the available save control. ✅ How to Confirm It Worked Reopen or refresh Brand Vault and review the fields again. Each required field should display your saved information instead of being blank or showing placeholder text. If any field is still empty, complete and save it again. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

📊 Download Detailed OTTO SEO Issue Reports

📋 Overview OTTO SEO scans your website for technical SEO issues and organises them into a clear, actionable report. You can review every issue directly inside the platform and download a detailed report to share with your team or clients. This article walks you through the full process. 🔍 Step 1: Open OTTO SEO In the left sidebar, click OTTO SEO. This takes you to your OTTO dashboard where all connected sites and their audit data are displayed. 🌐 Step 2: Select Your Website If you manage more than one site, use the site selector at the top of the page to choose the domain you want to audit. OTTO will load the most recent scan results for that domain automatically. ⚙️ Step 3: Run or Refresh the Site Audit To make sure you are working with the latest data, trigger a new scan: 1. Look for the Re-crawl or Run Audit button near the top of the OTTO dashboard. 2. Click it to start the scan. Depending on the size of your site, this may take a few minutes. 3. Wait for the progress indicator to complete before moving to the next step. If a recent scan already exists and no major changes have been made to your site, you can skip this step and use the existing results. 🛠️ Step 4: Review Technical Issues in the Dashboard Once the audit is complete, OTTO organises all detected issues by category. You will see sections covering areas such as: - Indexability — pages blocked from search engines - Meta tags — missing, duplicate, or over-length titles and descriptions - Page speed — performance factors slowing down your pages - Structured data — schema errors or missing markup - Links — broken internal and external links - Content — thin content, duplicate content, and missing headings Click any category to expand it and see a full list of affected pages along with a description of the problem and the recommended fix for each item. 📥 Step 5: Download the Detailed Issue Report To export the report: 1. Navigate to the issues section or category you want to export. To get a full report, make sure you are viewing all issues rather than a single category. 2. Look for the Export or Download Report button — typically displayed as a download icon or labelled button in the top-right area of the issues table. 3. Click the button. The report will download as a CSV or PDF file to your device, depending on the export option available. 4. Open the file to see every issue listed with its affected URL, issue type, severity level, and the proposed fix or recommended action. 💡 Tips for Getting the Most from Your Report - Sort by severity — prioritise critical and high-severity issues first for the biggest SEO impact. - Filter by category — if you want to focus on one area (for example, only meta tag issues), apply filters before exporting so your report is scoped to that category. - Schedule regular audits — run a fresh scan at least once a week to catch new issues introduced by site updates or new content. - Share with your developer — the exported report is formatted to be shared directly with a developer or technical team member, as it includes both the issue description and the fix. ❓ Frequently Asked Questions Why do I not see a Download button? Make sure the audit has fully completed. If the scan is still running, the export option may not appear yet. Wait for the progress bar to finish and then refresh the page. Can I download reports for individual issue categories? Yes. Navigate into a specific category (for example, Broken Links), then use the export option within that view to download only those issues. How often is the audit data refreshed? OTTO can run automatic scans on a set schedule. You can also trigger a manual re-crawl at any time using the Re-crawl button as described in Step 3. 💬 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.

🔍 Tracking Pixels in Site Audit Alt Text Tasks

🧩 Why Tracking Pixels (Usually) Don't Appear in Alt Text Tasks Site Audit builds alt-text tasks from the <img> elements it finds on each crawled page. Images are analyzed as part of the page that hosts them — they are never crawled or audited as separate URLs. Before an image is stored, two automatic filters run: - Known tracking-pixel URLs are skipped — including bat.bing.com, Facebook pixel URLs, Google Analytics collection URLs, and DoubleClick domains. - Tiny images are skipped — images declared as 0×0 or 1×1 never become alt-text tasks. Because of this, the common tracking pixels should never reach your alt-text task list. If your list is still filling up with third-party images, they are pixels the automatic filter does not recognize yet. 🎯 What This Means for Your SEO Score When unrecognized pixels dominate your missing-alt-text task list, two problems occur: - Your overall SEO score appears lower than it actually is for real content. - Your team wastes time reviewing non-actionable items instead of fixing genuine image accessibility issues. Clearing them out lets the audit surface only the images that truly need your attention. 🛠️ What Actually Works — and What Doesn't What doesn't work: adding the pixel's domain (for example bat.bing.com) to the Site Audit URL exclusions list. URL exclusions are matched against the URLs of your own pages — they never match the source of an image embedded in a page — so an external image domain in that list has no effect on image tasks. What works: 1. Delete or ignore the individual tasks. This is the fastest option. Note that if the image is still not recognized as a tracker, the same task can reappear after the next recrawl. 2. Exclude the hosting page — only when that page itself is low-value (for example a thank-you or confirmation page loaded with pixels). In OTTO SEO → Site Audit → All Audits, click the ⋮ menu on your site's row, select Crawl Settings, and add a URL exclusion matching that page's path. This removes all analysis for that page, not just its images, so use it only for pages you do not want audited anyway. 3. Report a recurring unrecognized pixel to our support team. Search Atlas maintains an internal tracker filter, and a new pixel pattern can be added there so it is skipped for every site — this is the durable fix. ✅ Best Practices for Managing Alt Text Tasks - Prioritise content images first: sort remaining tasks by page priority or organic traffic to fix the highest-impact images first. - Review after tag deployments: new marketing or analytics tools can inject images the filter doesn't know yet. Check your alt-text task list after major tag changes. - Use descriptive alt text: for real images that are flagged, write concise, keyword-relevant descriptions that reflect both the image content and the page topic. ⚠️ Important Considerations - Third-party alone does not exempt an image. A real <img> element with real dimensions that is not on the tracker list can be legitimately flagged — in that case the correct fix is to give it proper alt text, not to suppress the task. - Tag-manager scripts are handled separately. Pixels injected purely by JavaScript are not <img> elements in the crawled HTML, so they do not produce image tasks at all. 💬 Need Further Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. Additional Notes After a recrawl, deleted tasks for an unrecognized pixel may return — that repetition is the signal to report the pixel pattern to support so it can be added to the internal tracker filter.

🔍 Find and Access Previous Site Explorer Audits

🗂️ Overview Every Site Explorer audit you run in Search Atlas is automatically saved to your account. You do not need to re-run an audit to view previous results — your audit history is accessible from the Site Explorer section of the platform. 📍 Where Your Previous Audits Are Stored Previous audits are not stored on the Home page. They live inside the Site Explorer tool, organised by project or domain. Follow the steps below to find them. 🚀 How to Access a Previous Audit 1. Log in to your Search Atlas account. 2. In the left sidebar, click Site Explorer. 3. You will land on the Site Explorer section, which lists the domains and projects you have previously audited. 4. Locate the domain or project you want to review and click on it to open the saved audit results. ⚠️ Common Reasons You Cannot Find an Audit - Wrong account: Confirm you are logged in to the correct Search Atlas account. Audits are tied to the account that ran them. - Different project workspace: If your account uses multiple workspaces or projects, make sure you are viewing the correct one. - Audit was deleted: Deleted audits cannot be recovered. If you believe an audit was removed by mistake, contact our support team. If you have checked the above and still cannot locate a previous audit, our support team can help you identify where it may be stored or whether it still exists on your account. Please have your domain name and approximate audit date ready when reaching out. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Understand HTTP Codes and Indexing

🧭 Overview HTTP status codes and indexing directives tell search engines how to handle URLs. They are related, but they do not mean the same thing. A correct fix depends on the intended state of each URL. ✅ What a 200 status means A 200 response means the server successfully returned content. It does not guarantee that Google will index the URL. Google can pass the content to its indexing systems, but indexing is not guaranteed. Use 200 for active, useful pages. If duplicate or low-value copies should not appear in search, add a noindex directive or consolidate the pages with the appropriate canonical setup. 🚫 How noindex works noindex tells search engines not to include a URL in search results. It can be delivered in a meta robots tag or an HTTP X-Robots-Tag response header. Use noindex for active routes that must remain available, such as dashboards, previews, registration pages, staging interfaces, or other functional URLs. For example, a live signup path such as dashboard.searchatlas.com/register should use noindex, not 410. Make sure search engines can crawl the URL to see the noindex directive. Blocking the URL in robots.txt can prevent Google from reading the directive. 🗑️ 404 versus 410 Both 404 Not Found and 410 Gone are 4xx responses. Google treats all 4xx responses, except 429, similarly: previously indexed URLs are removed over time, newly discovered URLs are generally not processed, and crawling gradually decreases. There is no reliable Google behavior where 404 URLs are retried for months while 410 URLs are immediately removed. Choose the status based on the URL's intended state: - 404: Use when a page is unavailable and no permanent retirement signal is required. - 410: Use as a clear convention for intentionally retired routes that will not return. - noindex: Use when the route is active and must remain accessible. A status-code change alone may not stop discovery. Remove retired URLs from XML sitemaps and internal links, and update other references that continue to expose them. 🔎 Why noindex rows can persist SEO reports may continue showing URLs as excluded by noindex after the fix is live. These rows are usually crawl-time observations, not proof that the directive failed. Google validation can take about two weeks or longer. Compare the last crawl date with the fix date, inspect the current response headers, and use URL Inspection when available. Treat the issue as a regression only if the live response was incorrect when Google recrawled the URL. Do not restart validation solely because an older report row remains. 🛠️ Recommended verification steps 1. Confirm the intended state for each URL before selecting 404, 410, 200, or noindex. 2. Check the live HTTP status and confirm the expected X-Robots-Tag or meta robots directive. 3. Verify that robots.txt does not block Google from accessing a URL that needs to be evaluated for noindex. 4. Remove retired URLs from sitemaps and internal links. 5. Record the fix date and compare it with the URL's last crawl date before escalating. 6. Recheck each host live; do not rely only on older crawl data or report rows. 📊 Where to review Search Atlas data In Search Atlas, open OTTO SEO from the left sidebar. Use Crawl Monitoring for crawl observations, All Audits for detected issues, and Knowledge Base for related guidance. Review the live response before creating or reopening a task. 💬 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.

🚫 Exclude Tracking Pixels from Site Audit Alt Text

🔍 Why Tracking Pixels Appear in Alt Text Tasks When Search Atlas crawls your site, it detects every image — including invisible 1×1 tracking pixels served by third-party domains such as bat.bing.com, Google Tag Manager, Facebook Pixel, and similar advertising or analytics services. These images have no meaningful content, so adding alt text to them does not improve accessibility or SEO. However, because they are technically missing alt attributes, they appear in your Site Audit alt text tasks and can inflate the issue count significantly, dragging down your overall SEO score. The correct fix is to exclude these third-party URLs directly inside OTTO settings so Search Atlas ignores them during analysis. ⚙️ How to Exclude Tracking Pixel URLs in OTTO 1. Open the platform and navigate to OTTO SEO → SEO Automation using the left sidebar (URL: /seo-automation-v3). 2. Select your project and open OTTO for the site you want to configure. 3. Locate the Settings or Exclusions section within OTTO. 4. Find the field that allows you to add URLs or URL patterns to exclude from audits. 5. Enter the tracking pixel domain or URL pattern you want to ignore. For example: - bat.bing.com — Microsoft Advertising pixel - facebook.com/tr — Facebook Pixel - google-analytics.com/collect — Google Analytics beacon - googletagmanager.com — Google Tag Manager 6. Save your exclusions. 7. Re-run the Site Audit so Search Atlas recrawls your site with the new exclusion rules applied. Once the audit completes, the excluded tracking pixel URLs will no longer appear in your alt text tasks or count against your SEO score. ✅ How to Confirm the Exclusions Worked After the audit finishes, open your Site Audit results and navigate to the Images or Alt Text task list. The number of missing alt text issues should drop substantially. If you still see entries from the excluded domains, double-check that the URL pattern you entered matches the exact format shown in the audit detail — including any subdomains or path prefixes. 💡 Best Practices for Managing Third-Party Image Exclusions - Use domain-level patterns where possible. Excluding the root domain (e.g., bat.bing.com) covers all paths served from that domain, so you do not need to add individual pixel URLs one by one. - Review your exclusion list periodically. If you add new advertising platforms or analytics tools, add their beacon domains to the exclusion list before your next audit to keep your score accurate. - Only exclude true third-party tracking assets. Do not exclude images hosted on your own domain or CDN — those may have legitimate alt text requirements that affect real users and accessibility scores. - Document your exclusions. Keep a record of which domains you have excluded and why, so your team understands why certain images do not appear in audit tasks. 🧩 Understanding the Impact on Your SEO Score Search Atlas calculates your SEO score based on actionable issues on your site. Tracking pixels are not actionable — you cannot and should not add descriptive alt text to a 1×1 invisible beacon. By excluding them, your score reflects only real opportunities for improvement, giving you a more accurate picture of your site's SEO health and helping you prioritise the tasks that actually move the needle. 🆘 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.

📊 Understanding Site Auditor Report Export Accuracy

🔍 Overview The Site Auditor generates detailed reports about technical SEO issues across your website. When you export that report — for example, as a Google Doc — you may notice data that looks unexpected, including unfamiliar URLs, issue descriptions that seem off, or formatting that makes it hard to match a specific URL to a specific problem. This is a known UX and export accuracy issue that our team investigates on a case-by-case basis. ⚠️ Why Exported Reports May Look Inaccurate Export accuracy issues usually fall into one of these categories: - Stale crawl data: The report reflects the last completed crawl. If your site has changed since then, the exported data will not match your current live site. - Formatting limitations in Google Docs: Large tables with many URLs and issue types can lose column alignment or wrap text in ways that make it hard to read which URL is linked to which issue. - Issue descriptions pulled from raw metadata: Some issue labels and descriptions are generated from page-level metadata (like meta titles, alt text, or heading tags). If your site contains typos or misspellings in those on-page elements, they will appear exactly as-is in the export — the auditor reports what it finds, not a corrected version. - Multiple issues per URL: A single URL can trigger several different issue types. In an exported document, these may appear as separate rows, which can make it look like there are more affected pages than there actually are. ✅ What to Do If Your Export Looks Incorrect Because this is a bug-category issue, resolution typically requires our team to investigate the specific data and export in question. To help us resolve this as quickly as possible, please have the following ready when you reach out: - Your project name (the exact name as it appears in your Search Atlas account) - A description of the unexpected data — for example, URLs you do not recognize, issue counts that seem wrong, or formatting problems in the exported document - The date and time when you generated or exported the report - A screenshot or copy of the exported report showing the problematic data - Any error messages displayed during the export process, copied exactly as they appeared 📋 General Tips for Reading URL-Level Issues While our team investigates, the following may help you work with your data in the meantime: - Use the in-platform view first: The platform groups issues by type and lets you expand each one to see every affected URL. This is generally clearer than the exported document and can help you identify whether the issue is in the export itself or in the underlying crawl data. - Check whether the data matches the in-platform view: If the in-platform view looks correct but the export does not, that difference is important information to share with our team when escalating. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Fix Sitemap URLs and Manage Competitors in Site Matrix

Overview Two common issues can affect your Site Matrix experience: your sitemap displaying preview.builder URLs instead of your custom domain, and irrelevant companies appearing as auto-suggested competitors. This article walks you through how to resolve both issues step by step. Why Your Sitemap Shows preview.builder URLs When your website is built on a hosted website builder, the sitemap may default to the builder's staging or preview domain rather than your live custom domain. To resolve this, you need to ensure your custom domain is set as the primary domain in your website builder's settings, then regenerate your sitemap and re-submit it inside Site Matrix so it can crawl the correct URLs. 1. Log in to your website builder and navigate to your domain settings. 2. Confirm your custom domain is marked as the primary domain and that the preview or staging domain is not set as default. 3. Regenerate your sitemap from your builder's SEO or sitemap settings. 4. Copy the updated sitemap URL — it should now begin with your custom domain. 5. Inside Search Atlas, open Site Matrix and locate the sitemap settings for your project. 6. Paste the updated sitemap URL into the appropriate sitemap setting and save your changes. If the sitemap URL still shows a preview domain after completing these steps, contact your website builder's support to ensure the sitemap generation is tied to your custom domain, then repeat the steps above. How Auto-Suggested Competitors Are Generated Site Matrix automatically suggests competitors based on keyword overlap and search visibility data. If your project domain is new, not yet fully indexed, or operates in a niche vertical such as iGaming, the algorithm may surface companies from broader or adjacent industries before it has enough data to refine its suggestions. This is expected behaviour during the early stages of a new project. The solution is to manually manage your competitor list by removing irrelevant suggestions and adding the specific competitors that matter to your business. How to Manage Competitors in Site Matrix To update your competitor list, navigate to your project inside Site Matrix within Search Atlas and locate the competitor management area for that project. From there you can remove any auto-suggested competitors that are not relevant to your niche and add or pin the competitor domains you want to track. Once saved, Site Matrix will use your updated competitor list going forward. If you are unsure where to find the competitor management area in your current account view, or if the option does not appear as expected, please have the following ready when reaching out for help: your project name, your custom domain, and a brief description of the competitors you are trying to add or remove. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Find Non-Parsable Schema JSON

🔎 What “non-parsable JSON” means The Site Auditor reports a non-parsable JSON object when it finds structured data that cannot be read as valid JSON. This usually happens inside a JSON-LD script, marked with application/ld+json. Because the object cannot be read, the auditor may not display the specific schema type or error location. 🧭 Locate the affected JSON-LD 1. Open the URL listed in the Site Auditor issue. 2. View the page source. In most browsers, right-click the page and select View page source. 3. Search the source for application/ld+json. 4. Review each JSON-LD script on the page. The affected object may be in the page template, a plugin, a tag manager, or custom code. 5. Copy each complete JSON-LD block into a JSON validator until you identify the block that returns a parsing error. 🛠️ Validate and identify the error Paste the complete contents of the JSON-LD script into a trusted JSON validator or code editor. A valid JSON object must use double quotation marks around property names and text values, include commas between properties, and close every brace and bracket. Check the validator’s line and column reference. Then compare that location with the source code to find the exact character causing the issue. Common causes include: - Missing or extra commas - Unclosed quotation marks, braces, or brackets - Single quotation marks instead of double quotation marks - Unescaped quotation marks or special characters in text - Comments or JavaScript expressions inside the JSON - Multiple objects combined without a valid array or graph structure - Template variables that were not replaced with valid values ✅ Fix and verify the markup 1. Update the source that generates the invalid JSON-LD, such as the CMS template, schema plugin, tag manager, or custom script. 2. Validate the corrected block again before publishing. 3. Clear any site, CDN, or plugin cache. 4. Open the affected URL and check the page source to confirm the corrected markup is live. 5. Run the Site Auditor scan again. The issue may remain until the auditor recrawls the page. 📌 If several JSON-LD blocks exist Test each application/ld+json block separately. One valid block does not make another invalid block parsable. Also check content inserted dynamically after the initial page load, because a plugin or tag manager may add a second JSON-LD object. 💬 Need help? When contacting support, include the affected URL, the auditor issue, and the invalid JSON-LD block with sensitive information removed. 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.

🔧 Wix Post-Render Content Overwrites Explained

🔍 What Is the Post-Render Overwrite Issue? When Search Atlas publishes SEO changes to a Wix-hosted site, Wix can re-render the page after publishing and overwrite those changes with its own cached or default values. This is known as a post-render overwrite. The result is that your Search Atlas optimisations appear to save correctly inside the platform but do not persist on the live Wix site. This behaviour has been identified as a recurring defect affecting Wix integrations and is actively tracked by our engineering team. ⚙️ What Specifically Gets Overwritten? Metadata and content changes made through Search Atlas on Wix-connected sites may not persist after Wix re-processes the page. This can affect page-level SEO fields and content elements that Search Atlas writes via the Wix integration. 📋 Why Does This Happen? Wix uses a proprietary rendering pipeline that re-processes page content after external publish events. When Search Atlas writes metadata via the Wix API, Wix's renderer can execute a second pass that pulls values directly from its internal CMS database — overwriting the changes made by Search Atlas before the final HTML is served to visitors or cached by Wix's CDN. This is a known defect caused by a conflict between Search Atlas's publish-sync process and Wix's post-render behaviour. Our engineering team is actively working to address the underlying integration issue, and verification on affected sites is ongoing. 🛠️ What Has Been Fixed So Far? Our engineering team has shipped updates to improve the reliability of content and metadata publish events on Wix-connected sites. These fixes reduce the frequency of overwrites; however, due to the nature of Wix's rendering pipeline, full verification across all affected pages requires additional monitoring. Our team continues to test and confirm resolution on impacted sites. ✅ Steps to Take Right Now 1. Confirm which pages on your Wix site are affected by checking whether your saved changes appear on the live page after publishing. 2. Note the exact page URLs and the specific fields that appear to be overwritten (for example, page title, heading, or image metadata). 3. Note the approximate time you published the changes, so our team can cross-reference logs. 4. Contact our support team with your project name, the affected page URLs, the fields being overwritten, and the timestamps of your publish attempts — this will allow our engineering team to investigate your specific case as efficiently 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.

🔍 Understanding HTTPS Redirect False Positives

📋 What This Article Covers If your Site Audit is flagging "HTTP doesn't redirect to HTTPS" or "Protocol/WWW variants don't redirect to the same place" as issues — but your redirects are actually working correctly — you may be encountering a known false positive. This article explains what this means, how to verify your redirects, and what information to have ready when contacting our team. 🔬 Why This Happens In some cases, the Search Atlas Site Audit crawler may flag HTTPS or WWW redirect issues even when your redirects are correctly configured. This is a known false positive that our engineering team is aware of and actively investigating. The crawler may not always detect or fully interpret certain redirect setups, which can result in an inaccurate flag in your audit report. ✅ How to Verify Your Redirects Are Working Before reporting the false positive, confirm your redirects are functioning correctly: 1. Test in your browser: Type your HTTP URL (for example, http://yoursite.com) into the address bar and press Enter. If it automatically changes to HTTPS, your redirect is working. 2. Check all variants: Test all four versions of your domain — HTTP, HTTPS, WWW, and non-WWW. They should all resolve to a single canonical URL. 3. Use a redirect checker: Free tools like Redirect Checker or HTTPStatus.io can confirm your redirect chains and status codes. 4. Verify in Google Search Console: Check that Google has indexed the HTTPS version as the canonical URL. 🛠️ What to Do If You Confirm a False Positive If you have verified that your redirects are working correctly but the Site Audit is still flagging them as issues, this is a known false positive that our team is investigating. To help us resolve this more efficiently, please gather the following information before reaching out: - Project name: The name of the project in Search Atlas where the false positive appears. - Exact flagged issue text: The specific redirect issue message shown in your Site Audit report. - Domain URL(s) affected: The URLs or domain variants that are being incorrectly flagged. - Proof redirects work: A screenshot or note confirming that your redirects resolve correctly when tested in a browser or third-party redirect checker. Our engineering team is actively working on improving the crawler's ability to accurately detect redirect configurations so that these false positives are reduced in the future. If you need further assistance, open 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 Autopilot History and Export Reports

🔍 What Is Autopilot Deployment History? Site Auditor Autopilot automatically detects and fixes on-site SEO issues on your behalf. Every action it takes is logged so you always have a clear, auditable record of what was changed, when it happened, and what the outcome was. This history is available directly inside the platform without any additional setup. 📍 How to Find Your Autopilot Deployment History To view the history of automated changes Autopilot has made for a site, navigate to the Site Auditor section of the platform and open the Autopilot area for the project you want to review. From there, look for the history or log view, which displays a chronological record of every automated action Autopilot has completed for that site. 📋 What the Deployment History Shows Each entry in the deployment history log typically includes details such as: - When the change occurred — a timestamp for the automated action. - The type of SEO issue addressed — the category of problem that was fixed (for example, a missing meta description or a duplicate title tag). - The affected page — the URL where the fix was applied. - What action was taken — a description of what Autopilot changed or added. - The outcome — whether the fix was applied successfully or requires attention. You may be able to filter or sort the history to focus on specific time periods, issue types, or statuses. 📤 Exporting Your Autopilot Reports Search Atlas includes export functionality within the Site Auditor Autopilot area so you can share records of automated changes with clients, stakeholders, or your internal team. To generate an export, open the Autopilot history view for your project and look for an export or download option. The export will contain the logged details for the automated actions Autopilot has performed. If you cannot locate the export option or are unsure which report format is available for your plan, our support team can confirm the exact steps and available formats for your account. ❓ Troubleshooting and Next Steps If you cannot find the Autopilot history view, the export option is not visible, or the log does not appear to reflect recent changes, please have the following ready when you reach out: - The name of the project or site you are reviewing. - A description of what you expected to see versus what you are seeing. - Any error messages or unexpected behavior you have encountered. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔄 Understanding Automatic and Manual Site Recrawls

🗓️ How the Weekly Automatic Recrawl Works Search Atlas automatically recrawls your domain once per week. This recrawl refreshes your site audit data, updates page-level insights, and ensures your SEO recommendations reflect the current state of your website — no action required on your part. The weekly recrawl runs as part of a scheduled batch process. You do not need to manually trigger this recrawl — it happens automatically in the background, and updated results will appear in your dashboard after the process completes. 🛠️ How to Manually Reprocess Your Domain If you need fresher data before the next scheduled recrawl — for example, after publishing a batch of pages or implementing technical fixes — you can trigger a manual reprocess at any time. 1. Log in to your Search Atlas account. 2. Navigate to the Site Audit section from the left-hand menu. 3. Select the domain you want to reprocess. 4. Locate and trigger the manual reprocess option within the audit dashboard. 5. Wait for the crawl to complete. Depending on the size of your site, this may take a few minutes to several hours. Once the manual reprocess is complete, your audit scores, issue lists, and page-level data will all reflect the latest crawl results. ⚠️ Known Limitations to Be Aware Of In some cases, you may notice that certain target pages were not crawled or that suggestions were not generated after a reprocess. This can happen when: - Pages are newly added and have not yet been indexed by the crawler. - A reprocess was triggered very shortly after a previous crawl completed. If your manual reprocess appears to be stuck or if suggestions are still missing after the crawl finishes, please refer to the troubleshooting steps below. 🔍 Troubleshooting a Stuck or Incomplete Reprocess If your reprocess does not complete as expected, try the following steps before reaching out for support: - Refresh your browser and return to the Site Audit dashboard to check whether the crawl status has updated. - Wait 30 minutes — large sites can take time to fully process after a crawl completes. - Trigger a second reprocess — occasionally, initiating a fresh crawl resolves an incomplete previous run. - Confirm that the domain you selected is the correct and verified domain in your account settings. If none of the above steps resolve the issue, our support team can investigate directly and escalate 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.

⚠️ OTTO Sites and Site Audit Project Quotas Explained

🔍 Overview If you encounter a quota limit error when trying to add a new OTTO site — even though your OTTO slots appear available — the most likely cause is your Site Audit project quota. OTTO Sites and Site Audit Projects are two separate quotas, but OTTO always attaches to a Site Audit project for the same domain. This article explains how the two quotas work together and how to free up space. 📦 How the Two Quotas Work Your plan includes two separate limits: - OTTO Sites — the number of sites that can have OTTO active. - Site Audit Projects — the number of Site Audit projects you can run. They are not one shared pool, but they are connected: adding OTTO to a site requires that site's Site Audit project to exist. If the domain does not already have one, a Site Audit project is created automatically first, and then the OTTO project is added. - If the domain already has a Site Audit project, adding OTTO uses one OTTO site slot only. - If the domain is new, a Site Audit project will be created automatically first, so you need a free Site Audit project slot (for that domain's Site Audit) and a free OTTO site slot. For example, if all your Site Audit project slots are in use by other domains, you cannot add OTTO to a brand-new domain, even if you still have OTTO site slots available. 🚨 Why the Error Appears The error appears when one of the two quotas is full: either your OTTO Sites limit is reached, or the new domain has no Site Audit project and your Site Audit Projects limit is reached. ✅ How to Resolve the Conflict 1. Check your OTTO Sites usage against your OTTO Sites limit. 2. Check your Site Audit Projects usage against your Site Audit Projects limit. 3. If Site Audit Projects is full, remove Site Audit projects for domains you no longer need to free a slot for the new domain. 4. If OTTO Sites is full, remove OTTO from sites you no longer manage, or add OTTO site slots with an OTTO top-up. 5. Try adding the OTTO site again. 💡 Tips for Managing Your Quota - Review both quotas regularly so you only use slots for domains you are actively working on. - Remember OTTO top-ups add OTTO site slots only — they do not increase your Site Audit Projects limit. - Plan ahead when onboarding new clients: before adding OTTO to a new domain, confirm you have a free Site Audit project slot and a free OTTO site slot. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Twitter Cards vs Open Graph

📘 What are Open Graph tags? Open Graph tags are social-sharing metadata that describe a webpage when it is shared on platforms such as Facebook and LinkedIn. They can control the preview title, description, image, and URL shown with the shared link. Open Graph tags use the og: prefix. Common examples include og:title, og:description, og:image, and og:url. 🐦 What is a Twitter Card? A Twitter Card is the preview shown when a webpage is shared on X, formerly known as Twitter. Twitter Card metadata tells X how to display the page, including its title, description, image, and card layout. Twitter Card tags use the twitter: prefix. Common examples include twitter:card, twitter:title, twitter:description, and twitter:image. ⚖️ What is the difference? - Open Graph: A general social-sharing standard used by platforms including Facebook and LinkedIn. - Twitter Cards: Metadata specifically used to guide how a page appears when shared on X. - Prefixes: Open Graph tags begin with og:, while Twitter Card tags begin with twitter:. - Purpose: Both improve link previews, but each platform may read a different set of tags. Using both types of metadata can help your pages display correctly across different social platforms. 🛠️ Which tags should you add? For most pages, add the main Open Graph tags and the key Twitter Card tags below: - og:title and twitter:title - og:description and twitter:description - og:image and twitter:image - og:url - twitter:card Use clear, accurate text and a relevant image. Make sure the image is accessible to crawlers and that the page information matches the content visitors will find. 📊 How Search Atlas helps Search Atlas’s Site Audit can detect and audit Open Graph and Twitter Card tags on your pages. Review the audit results to find missing or incomplete metadata, then update the page templates or individual pages as needed. ✅ Quick checklist 1. Confirm your page has Open Graph tags. 2. Confirm your page has Twitter Card tags. 3. Check that titles and descriptions accurately describe the page. 4. Use a suitable, accessible social-sharing image. 5. Run a Site Audit after making updates. 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.

🚀 Refresh Stale Core Web Vitals Data

🔍 Why your score may look outdated A site recrawl and a Core Web Vitals update are separate processes. A recrawl checks your pages again, while Core Web Vitals may use Google Chrome User Experience Report (CrUX) field data. CrUX data reflects real-user experiences and may not change immediately after your site updates. Your dashboard can therefore show the same score even when the latest crawl completed successfully. A page may also have no available CrUX field data, especially for low-traffic pages or newly published URLs. 🔄 Refresh your Search Atlas data 1. Open Home from the left sidebar. 2. Select Refresh data. 3. Return to the relevant project and review the Core Web Vitals panel. 4. Check the panel’s Last checked date to confirm when the data was evaluated. If the score still has not changed, allow time for new field data to become available. Refreshing the dashboard cannot create new Google CrUX data. 📊 Check the latest site metrics 1. Open Site Metrics from the left sidebar. 2. Use Analyze to review the project and its current metrics. 3. Open History to compare previous results and identify whether the score changed. 4. Use Filters or Columns to focus on the affected URLs and metrics. 🛠️ What to verify on your website - Confirm the updated pages are publicly accessible and not blocked by robots.txt, authentication, or a firewall. - Check that the pages return a successful status and load correctly for mobile users. - Review changes affecting loading speed, responsiveness, images, JavaScript, caching, and third-party scripts. - Remember that Core Web Vitals are evaluated separately for mobile and desktop experiences. ⚠️ When no score is available If Google has no CrUX field data for a page or origin, Search Atlas may show an empty state instead of a score. This does not necessarily indicate a technical failure. Continue improving the page and check again after more eligible user data is collected. 💬 Get help with stale data If the Last checked date does not update after using Refresh data, or the site is crawlable but metrics remain unexpectedly stale, record the affected project, URL, and approximate recrawl time. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔍 Scheduled URL Crawl Frequency Explained

📅 What the crawl frequency means A scheduled crawl frequency tells Search Atlas how often a URL should be considered for crawling. For example, a setting of every 7 days means the URL is eligible to be crawled approximately every 7 days. It is not a guaranteed completion time. ⏳ Why a crawl may be delayed A URL can go beyond its selected frequency when crawl work is delayed or cannot be completed. Common reasons include: - Other scheduled crawl jobs are being processed first. - Temporary platform capacity limits or traffic bursts require crawl requests to be spread out. - The previous crawl was unsuccessful or did not complete. - The URL is being checked as part of another crawl or processing workflow. - Results and related recommendations are still waiting for downstream processing. These delays can cause a URL set to every 7–14 days to show a last crawl date from 30–90 days ago. ⚙️ Frequency settings are not normally removed If you manually set a recrawl frequency, the setting should remain active. A missed crawl does not mean the frequency was intentionally deactivated. The next eligible crawl may occur after the delayed work is processed. 🔎 How to check a delayed URL 1. Open the URL or project area where the crawl schedule is managed. 2. Confirm that the URL still has the expected frequency, such as every 7 or 14 days. 3. Review the last crawl date and any available crawl status or error details. 4. Check whether the URL is included in another active crawl workflow. 5. Allow time for queued work to complete, then refresh the crawl status. ✅ What you should expect Scheduled crawling is designed to prioritize recurring checks while managing crawl capacity safely. The selected frequency is the intended cadence, but actual crawl completion can vary. A delayed crawl does not necessarily indicate a problem with your URL or settings. 🛠️ When to request help Contact support if a URL remains unprocessed for an extended period, its frequency changes unexpectedly, or the crawl shows a persistent error. Include the project, URL, selected frequency, last crawl date, and any visible error message so the issue can be reviewed efficiently. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🗺️ Include Custom Post Types in Video and News Sitemaps

🔍 Overview If your video-sitemap.xml or news-sitemap.xml is returning an empty URL set despite having published pages, the most common cause is that your custom post types are not enabled in your sitemap configuration. This is a configuration step — not a missing feature or a plugin limitation. ✅ Before You Begin Confirm the following before adjusting your sitemap settings: - You have published pages or posts using a custom post type (for example, a Videos or News post type). - You have admin-level access to your WordPress dashboard. - MetaSync is installed and active on your site. 🛠️ How to Enable Custom Post Types in Your Sitemaps Follow these steps to include your custom post types in the video or news sitemap: 1. Log in to your WordPress dashboard and navigate to Search Atlas in the left-hand menu. 2. Go to Settings (Sitemap Settings page). 3. Open the Post Types tab (sometimes labeled Content Types). 4. Locate your custom post type (e.g. Videos or News) in the list and toggle it on to include it in the sitemap. 5. Save your changes. 6. Return to Sitemap Settings and click Regenerate Sitemap (or the equivalent regeneration button in your version) to force MetaSync to rebuild the sitemap index. 7. Visit your sitemap URL (e.g. yoursite.com/video-sitemap.xml or yoursite.com/news-sitemap.xml) and confirm that URLs are now appearing. ⚠️ Troubleshooting Empty Sitemaps If the sitemap is still empty after enabling the post type and regenerating, check the following: - Post type visibility: The custom post type may not be registered as public in your theme or plugin code. Ask your developer to confirm the post type is registered with public: true. - Post status: Only posts with a Published status are included in sitemaps. Confirm your pages are fully published and not saved as drafts. - Caching: Some caching plugins may serve an older version of your sitemap. Try clearing your site cache and reloading the sitemap URL. If you need further assistance, open 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 Find Your Site Crawl Results

🚀 Where to Find Crawl Results Your site crawl results live inside the OTTO SEO section of Search Atlas. To access them: 1. Open the left sidebar menu in your dashboard. 2. Click on OTTO SEO → All Sites (SEO Automation). 3. Locate the site you crawled in the list. 4. Click on the site name to open its detail view. All crawl findings, recommendations, and reports appear on this page. If you have multiple sites, use the search or filter options at the top of the list to quickly locate the one you need. 📊 Checking Crawl Completion Status Each site in the OTTO SEO list shows a status that tells you where the crawl stands in its lifecycle. Check the status next to your site to determine whether the crawl has finished. If the status indicates the crawl is still in progress, results will continue updating until it completes. Once the crawl is finished, full results will be available in the site detail view. 💡 Tips for Accessing Results Quickly If you feel like you have lost your crawl results, they are almost always still in the platform. Here are a few things to check: - Verify you are in the right workspace. If your account has access to multiple teams or projects, make sure you have the correct one selected from your Avatar Menu (👤). - Check your browser tab. If you navigated away during a crawl, the results page may have closed. Return to OTTO SEO → All Sites (SEO Automation) in the left sidebar to reopen it. - Allow time for processing. Larger sites take longer to crawl. If a site is still processing, give it time to finish before expecting full results. ⚙️ What to Do If Results Are Missing If you still cannot find your crawl results, try the following: 1. Refresh your browser page and navigate back to OTTO SEO → All Sites (SEO Automation) from the left sidebar. 2. Confirm the site was successfully submitted for a crawl. If the site does not appear in the list, the crawl may not have 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.

Site Audit Duration Expectations and Processing Times

⏱️ How Long Does a Site Audit Take? Site audits at Search Atlas can take anywhere from a few minutes up to 24 hours to complete. This is completely normal and expected behavior. The exact duration depends on factors specific to your website and current system load. Do not be concerned if your audit is still processing after an hour or two — this is part of the normal workflow. You do not need to restart or re-trigger the audit while it is in progress. 🔍 What Affects Audit Processing Time? The following factors can influence how long your site audit takes to finish: - Website size: Larger sites with hundreds or thousands of pages take significantly longer to crawl than smaller sites. - Current system load: During periods of high platform usage, audits may be queued and processed in sequence, adding to overall wait time. 🗺️ Where to Monitor Your Site Audit You can check the status of your site audit at any time within the platform. Results will populate automatically once the crawl is complete. You do not need to keep the page open while the audit runs. The platform processes audits in the background, and your results will be ready when you return. ✅ When Your Audit Is Complete Once your audit finishes, you will see the full results populated in the platform. If you launched the audit and return the next day to find it complete, that is entirely expected for larger websites. ⚠️ When to Be Concerned In most cases, your audit will complete on its own within 24 hours. However, you should reach out for support if your audit has shown no progress or status change for more than 24 hours. When escalating, please have the following ready: your project name, the URL of the site being audited, and the approximate time you launched the 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.

🔧 Installing Search Atlas Pixel Without Head Access

🗺️ Overview The standard Search Atlas pixel installation places a script tag inside the <head> section of your website. However, if you manage a franchise site, a locked-down CMS, or a platform where your parent organisation controls template access, you may not be able to edit the <head> directly. 📋 Before You Start Gather the following before attempting any method below: - Your Search Atlas pixel snippet (copy it from your Search Atlas dashboard). - Login credentials for whatever CMS access level you do have — even limited access may be enough. - Contact details for your franchise web administrator, in case you need to escalate a formal request. 🔍 Where to Find Your Pixel Snippet If you have not copied your snippet yet, log in to Search Atlas and navigate to your dashboard to locate the pixel snippet. If you are unsure where to find it, contact your Search Atlas account administrator or reach out to our support team for guidance. What to Do When You Cannot Access the Head Tag Because the specific steps for installing the Search Atlas pixel when head access is unavailable depend on your CMS, hosting environment, and account configuration, our support team will work with you directly to identify the correct approach for your setup. To help us resolve this as quickly as possible, please have the following ready when you contact us: - The name of your CMS or platform (e.g. a franchise-managed system, a proprietary CMS, etc.). - A description of what access level you currently have (e.g. page editor only, no template access). - Any error messages or limitations you have encountered when attempting installation. - Your Search Atlas account name or project name. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

📘 Why Site Audit Shows “0 Indexed Pages” Even When Pages Are Indexed

If your Site Audit shows "0 indexed pages" even though your pages are indexed in Google, this does not mean there is a problem with your site. This behavior happens when the scan has not finished processing all data yet. Once the scan completes, indexed pages and meta keyword data are detected correctly. 🧠 What's Actually Happening A new scan was triggered, and the scan takes time to complete. While processing, indexed pages may temporarily show as 0 and meta keywords may appear incomplete. After roughly 30–40 minutes, data begins to populate correctly. This is expected behavior. ⏱️ Expected Processing Time After running a scan, processing typically takes around 30–40 minutes. During this time, indexed pages may show 0 and new meta keywords may not appear immediately. Once processing finishes, values update automatically. ✅ What to Do 1. Trigger or confirm the scan has started. 2. Wait roughly 30–40 minutes. 3. Refresh the audit view. 4. Recheck indexed pages and meta keywords. 🚫 What You Do Not Need to Do - Do not rerun the scan repeatedly - Do not escalate to support immediately - Do not assume pages are not indexed Waiting for the scan to finish is the correct action. ❓ FAQs Why does it say 0 indexed pages when they are indexed? Because the scan has not finished processing indexing data yet. Is this a bug? No. This is expected while the scan is running. When should I worry? Only if indexed pages still show 0 well after the scan is fully completed. If you need further assistance, open 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 Indexer Input Field Improvements

The URL Indexer input field in the Authority section has been updated to include an https:// protocol placeholder and automatic validation, making it easier to submit URLs correctly without manual formatting. ✨ What's New Previously, the URL input field in the URL Indexer lacked a visible protocol placeholder, which could lead to submission errors or incorrectly formatted URLs. The field now displays an https:// placeholder by default and includes protocol validation and autocomplete, ensuring that submitted URLs are properly formatted before indexing begins. 🛠️ How to Use It 1. Navigate to the Authority section in your Search Atlas left sidebar. 2. Open the Indexer tool. 3. Click on the URL input field — you will see the https:// placeholder guiding your entry. 4. Begin typing your URL. If the protocol is missing, it will be automatically completed for you. 5. Submit your URL for indexing as usual. 📋 What to Expect The input field will now enforce proper URL formatting by prompting users with an https:// placeholder and validating the protocol before submission. URLs that do not include a valid protocol will be automatically corrected or flagged, reducing indexing errors caused by malformed entries. This change applies to all URL Indexer submissions going forward. If you need further assistance, open 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 Crawl Settings and Score Differences

🧭 Overview Site Audit crawls your website the way a search engine or browser would, then scores what it finds. Two things cause most customer questions: the user agent setting, and score differences between projects or between crawls. This article explains both and helps you pick the right settings. 🤖 What Is a User Agent? A user agent is a label a crawler sends to your website to say who it is. Your server can respond differently depending on that label. For example, it might serve a mobile version of a page to a mobile browser, or block an unfamiliar crawler. The user agent you choose in Site Audit controls how your site sees the crawler. That can change which pages load, which content appears, and which issues are reported. 📱 Why Is My Project Set to Chrome Mobile? If you see a project set to a Chrome mobile user agent and you don't remember changing it, this is usually not a mistake. Common reasons include: - It was the default or suggested option when the project was created. - Mobile-first reasoning: Google primarily uses the mobile version of a site for indexing, so a mobile user agent shows you something close to what Google evaluates. - A teammate with access to the project or account may have changed it. - Different projects can have different settings. Each project keeps its own crawl configuration, so one project's setting does not carry over to another. You can review the current setting at any time in the project's Site Audit settings. The exact option names may vary slightly as the platform is updated. ✅ Which User Agent Should I Use? There is no single right answer for every site, but this guidance works for most customers: - Search Atlas user agent: A good choice if you want a clean, clearly identified crawl. It's also easier to allow-list if your site has a firewall or security tool, because you can recognize it in your server logs. - Chrome mobile: A good choice if you want to see your site as a mobile visitor sees it. This is useful if mobile pages differ from desktop pages, or if you care about mobile-first indexing. - Chrome desktop: Useful if your desktop and mobile versions differ and you want to check the desktop experience specifically. Rule of thumb: If your site is responsive (the same pages for mobile and desktop), either the Search Atlas or Chrome mobile option will give very similar results. If your site blocks or limits crawlers, start with the Search Atlas user agent and allow-list it, or switch to a browser-style option. 🛠️ How to Change the User Agent 1. Open the project you want to update. 2. Go to Site Audit and open the crawl or audit settings for that project. 3. Find the User Agent option and select the one you want. 4. Save your changes. 5. Start a new crawl so the new setting is applied. Changing the setting does not rewrite past results. You need to run a fresh crawl to see how the new setting affects your score and issues list. 📊 Why Do Scores Differ Between Projects or Crawls? A Site Audit score reflects what the crawler found during that specific crawl. If two scores don't match, one of these factors is usually the cause: - Different user agents: A site may serve different content, redirects, or errors to a mobile crawler than to a desktop or custom crawler. - Different crawl limits: If one project crawls more pages than another, the score is based on a different set of pages. - Blocked or throttled requests: Firewalls, security plugins, or rate limits can block some pages. The crawler then records errors or skips pages, which changes the score. - Site changes between crawls: New pages, deleted pages, redirects, or fixed issues all shift the results. - Robots rules and exclusions: Pages blocked by robots.txt or excluded in your settings are not scored the same way. - Temporary server issues: Slow responses or short outages during a crawl can create errors that do not appear in the next one. 🔄 How to Compare Scores Fairly 1. Make sure both projects use the same user agent. 2. Check that the page limit and crawl settings match. 3. Confirm that no security tool is blocking the crawler on either site. 4. Run a new crawl on both projects at around the same time. 5. Compare the issue lists, not just the overall score, to see exactly what changed. Scores from other SEO tools may also differ from Search Atlas. Every tool crawls differently, checks a different set of issues, and weights them differently. Use each tool's score to track your own progress over time rather than to compare tools directly. 🚧 If the Crawl Seems Blocked Signs that your site may be blocking the crawler include a very low page count, many access errors (such as 403 or 429), or a crawl that stops early. To fix this: - Ask your developer or host to allow-list the Search Atlas user agent. - Check security plugins and CDN or firewall rules for bot-blocking settings. - Try a browser-style user agent as a test, then run a new crawl. 💡 Best Practices - Review the user agent on each project when you set it up, instead of relying on the default. - Keep settings consistent across projects you plan to compare. - Re-crawl after any change to settings or after major site updates. - Track the trend in your score over time, since small shifts between crawls are normal. 💬 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.

🛡️ How to Allowlist OTTO in Cloudflare and WAFs

🔎 Why OTTO Needs Firewall Access OTTO needs to visit your website to scan pages, detect issues, and apply optimizations. Security tools such as Cloudflare, Sucuri, Wordfence, or your host's firewall sometimes mistake automated visits for unwanted bots and block them. When that happens, OTTO may not work properly on your site. Adding OTTO to your allowlist (also called a whitelist) tells your firewall that these visits are safe. ⚠️ Signs OTTO Is Being Blocked - Site audits fail, stay empty, or show errors such as 403 (Forbidden) or 503 (Service Unavailable). - OTTO shows pages as unreachable even though they load fine in your browser. - Optimizations do not appear on your live pages. - You see repeated challenge pages (such as CAPTCHA) in your firewall logs for Search Atlas traffic. 📋 What You Need Before You Start - Admin access to your Cloudflare account, hosting panel, or security plugin. - The current list of OTTO IP addresses and the crawler user-agent details. Important: IP addresses can change over time, so we do not publish a fixed list in this article. To get the most up-to-date IPs, open the chat widget in the bottom-right corner of the platform and type human teammate. Using an outdated list is a common reason OTTO gets blocked again later. ☁️ How to Allowlist OTTO in Cloudflare Menu names can vary slightly depending on your Cloudflare plan and dashboard version. The general steps are: 1. Log in to your Cloudflare dashboard and select your domain. 2. Go to Security and open WAF. 3. Choose Custom rules and click Create rule. 4. Name the rule something clear, such as Allow OTTO Crawler. 5. Set the condition to IP Source Address****is in, then paste the OTTO IP addresses provided by our team. 6. Under the action, choose Skip and select the security features to skip, such as rate limiting, managed rules, and bot protections. 7. Place the rule at the top of your rule list so nothing else blocks the request first. 8. Click Deploy. Alternatively, you can add each IP under Security then WAF then Tools (IP Access Rules) and set the action to Allow. 🤖 Check Bot Protection Settings Even with an allow rule in place, Cloudflare's bot features can still challenge OTTO. Review these settings: - Bot Fight Mode / Super Bot Fight Mode: make sure the allow rule is applied or that verified or known traffic is not challenged. - Under Attack Mode: this shows a challenge page to every visitor and will block OTTO. Turn it off when you are not actively under attack. - Rate limiting: make sure OTTO IPs are excluded so scans are not cut off midway. - Browser Integrity Check: consider skipping it for the OTTO IPs if you still see blocks. 🧱 Other Firewalls and Security Tools The steps differ by tool, but the idea is the same: allow the OTTO IP addresses and skip bot or rate-limit checks for them. - Hosting firewalls (cPanel, Plesk, managed hosts): add the IPs to the allow list in your security or firewall section, or ask your host to do it. - WordPress security plugins: look for a whitelist or allowed IPs setting in plugins such as Wordfence, iThemes Security, or All In One WP Security. - Sucuri, Imperva, Akamai, AWS WAF: add the IPs to an allow list or create a rule that bypasses bot and rate-limit checks. - Server-level rules (.htaccess, Nginx, ModSecurity): make sure no rules deny the OTTO IPs or block the crawler's user agent. ✅ How to Confirm It Worked 1. Save and deploy your changes, then wait a few minutes for them to take effect. 2. Return to OTTO in Search Atlas and run a new scan or audit of your site. 3. Check that pages are crawled successfully and that errors such as 403 or 503 no longer appear. 4. If you have access to firewall logs, confirm the OTTO requests now show as allowed or skipped. 🛠️ Troubleshooting Tips - Still seeing 403 errors: check that your allow rule sits above other blocking rules and that every OTTO IP was entered correctly, with no extra spaces. - Works for some pages only: a rule on a specific path, such as login or admin pages, may be blocking OTTO. Review path-based rules. - Multiple security layers: if you use Cloudflare plus a hosting firewall plus a plugin, each one needs the allowlist. - Challenges returning after a while: the IP list may have changed. Ask for the latest list through chat. - Using a CDN or proxy: make sure the rule is applied at the layer that sees the visitor's real IP address. 🔐 Is Allowlisting Safe? Allowlisting only the specific OTTO IP addresses is safe and limited. It does not open your site to other traffic. Avoid allowing broad IP ranges you do not recognize, and review your rules from time to time to remove outdated entries. 💬 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. Let us know which firewall or security tool you use and any error messages you see, so we can help you faster.

🔍 GTM Installation and GSC Detecting OTTO Updates

📌 Overview If you installed OTTO through Google Tag Manager (GTM), you may wonder whether this stops Google Search Console (GSC) from detecting your OTTO updates. In most cases it does not, but there are a few things that can make changes look delayed or missing. This article explains what to expect and how to check that everything is working. 💡 How GTM and OTTO Work Together When OTTO is installed through GTM, your page loads first and GTM then runs the OTTO script. The script applies the optimizations, such as updated titles, meta descriptions, schema, or other on-page changes, after the page loads. Google can process JavaScript, so it can usually see changes applied this way. However, Google handles JavaScript-based changes in a second step, after it first fetches the basic page. This means: - Changes applied through GTM may be picked up more slowly than changes that are already in your page's source code. - GSC reports are not real time. Data is often delayed by 2 to 3 days, and reindexing can take days or weeks depending on your site. - If the GTM tag does not fire correctly, Google will not see the updates at all. ⚠️ Common Reasons GSC Seems to Miss OTTO Updates - The GTM container was not published. Saving a tag in GTM is not enough. You must click Submit and publish the container. - The tag is not firing on every page. The trigger should be set to fire on all pages you want OTTO to optimize. - Consent or cookie settings are blocking the tag. If your consent banner blocks tags until a visitor accepts, Google's crawler may never trigger the OTTO script. - Caching. Your site, hosting provider, or CDN may be serving an older version of the page. - Duplicate installation. Having OTTO installed in more than one way (for example, GTM and a direct code snippet) can cause conflicts. - Blocked resources. If a robots.txt rule or security setting blocks Google from loading scripts, it may not render your changes. - Normal indexing delay. Google may simply not have recrawled the page yet. ✅ How to Check That GTM Is Working 1. Open your GTM account and confirm the OTTO tag exists and the latest version is published. 2. Check the tag's trigger. It should fire on All Pages or on the specific pages you are optimizing. 3. Click Preview in GTM, enter your page URL, and confirm the OTTO tag shows as Tag Fired. 4. Visit the live page, right-click, and choose View Page Source or use your browser's Inspect tool. Check that the updated element, such as the title or meta description, shows the new value in the Elements panel. 5. Open your OTTO dashboard and confirm the page shows the update as deployed. 🔎 How to Check What Google Sees in GSC 1. Open Google Search Console and select your property. 2. Paste the page URL into the URL Inspection bar at the top. 3. Click Test Live URL. 4. Click View Tested Page and review the HTML tab. This shows the page after Google has rendered it, including changes made by scripts. 5. Check that the updated title, description, or other elements appear there. If the rendered HTML shows your OTTO changes, Google can see them. The remaining step is waiting for Google to recrawl and update its index. 🚀 Request Faster Recrawling - In URL Inspection, click Request Indexing for your most important pages. - Make sure your XML sitemap is submitted in GSC and up to date. - Avoid requesting indexing repeatedly for the same URL. It does not speed things up. ⏱️ What to Expect on Timing - Live Test results: immediate, and shows what Google can render today. - Search results updates: often several days to a few weeks. - GSC performance data: usually delayed by a couple of days. A change that appears in the live test but not yet in search results is usually a timing issue, not an installation problem. 🛠️ Troubleshooting Checklist - Confirm the GTM container is published and the OTTO tag fires in Preview mode. - Check that your consent banner is not blocking the tag. - Clear your site and CDN cache. - Make sure OTTO is installed only once, not in several places. - Confirm robots.txt does not block scripts needed for rendering. - Run the URL Inspection live test and compare the rendered HTML with your OTTO dashboard. - Wait a few days after changes, then recheck. 💬 Need More Help? If you have gone through the steps above and Google still does not show your OTTO updates, our team can review your setup with you. Have your website URL and an example page 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.

🗺️ How to Create a Sitemap for Your Website

📌 Quick Answer Search Atlas does not currently generate sitemap files. A sitemap is created and hosted on your own website, so the best way to get one is through your content management system (CMS) or a sitemap plugin. Most platforms can do this automatically in a few minutes. This article shows you how. 🗺️ What Is a Sitemap? A sitemap is a file, usually located at yourdomain.com/sitemap.xml, that lists the important pages on your website. Search engines like Google and Bing use it to find and understand your pages faster. A sitemap is especially helpful if your site is new, large, or has pages that are not well linked to each other. ❓ Why Doesn't Search Atlas Generate Sitemaps? A sitemap has to live on your website's server and stay up to date as you add, remove, or change pages. Your CMS or hosting platform is the right place to manage that, because it knows exactly what is published on your site at any moment. Using your CMS or a plugin means your sitemap updates on its own and stays accurate. 🛠️ How to Create a Sitemap by Platform Find your platform below and follow the matching steps. Menu names can change slightly over time, so look for similar options if yours differs. - WordPress: Recent versions create a basic sitemap automatically at yourdomain.com/wp-sitemap.xml. For more control, use an SEO plugin such as Yoast SEO, Rank Math, or All in One SEO. Enable the XML sitemap feature in the plugin settings. - Shopify: A sitemap is created automatically at yourdomain.com/sitemap.xml. No setup is needed. - Wix: A sitemap is created automatically at yourdomain.com/sitemap.xml. You can review it in your Wix SEO settings. - Squarespace: A sitemap is created automatically at yourdomain.com/sitemap.xml. - Webflow: Open your Project Settings, go to the SEO tab, and turn on auto-generate sitemap. Then publish your site. - Custom-built or other sites: Ask your developer to generate one, or use a reputable online sitemap generator tool. Upload the file to the root of your website. ✅ How to Check That Your Sitemap Works 1. Open a new browser tab. 2. Type your domain followed by /sitemap.xml (or /wp-sitemap.xml for default WordPress). 3. Confirm you see a list of your page URLs. 4. Make sure the pages listed are the ones you want search engines to find. If you see a 404 error, the sitemap may be turned off or saved at a different address. Check your CMS or plugin settings. 🚀 How to Submit Your Sitemap to Search Engines Once your sitemap is live, tell search engines where to find it. 1. Sign in to Google Search Console and select your website. 2. Open Sitemaps in the left-hand menu. 3. Enter your sitemap address, for example sitemap.xml, and click Submit. 4. Repeat the process in Bing Webmaster Tools if you want to be found on Bing. You can also add a line to your robots.txt file that reads Sitemap: https://yourdomain.com/sitemap.xml. This helps search engines find it on their own. 💡 Best Practices - Include only pages you want to appear in search results. - Leave out pages marked noindex, redirected pages, and duplicate pages. - Use only one main sitemap or sitemap index to avoid confusion. - Keep your sitemap automatic so it updates when you publish new content. - Resubmit only if the sitemap address changes. Search engines recheck it regularly. 🔧 Troubleshooting Common Issues - Sitemap shows a 404 error: Make sure the sitemap feature is enabled and save your permalink or site settings again. - Search Console says it could not fetch the sitemap: Check that the address is correct and that the file is not blocked by robots.txt or a security plugin. - Pages are missing: Check that those pages are published and not set to noindex in your CMS or SEO plugin. - Two sitemaps appear: This is common on WordPress when a plugin and the default sitemap are both on. Turn off the one you don't need. 💬 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 Robots.txt AI Crawler Warnings

🤖 What the warning means Search Atlas reports this warning when your robots.txt file appears to block crawlers used by AI services, such as large language model (LLM) crawlers. The warning does not automatically mean your website is broken or that search engine visibility is affected. A rule such as User-agent: * followed by Disallow: / blocks every crawler from the entire website, including AI crawlers. Rules that block only selected folders, checkout pages, cart pages, internal search results, or URL parameters may be intentional and are not necessarily problems. 🔍 Check which rule triggered the warning 1. Open your website's robots.txt file by visiting https://your-domain.com/robots.txt. 2. Look for User-agent: * and any broad Disallow rules. 3. Check whether the rule blocks the entire site with Disallow: /, or only specific paths. 4. Review whether named AI crawlers, such as GPTBot, ClaudeBot, Google-Extended, or other AI user agents, are blocked. Do not remove rules automatically. E-commerce protections, private areas, duplicate URL controls, and parameter-based disallows can be valid. The key concern is whether important public pages are unintentionally blocked from AI crawlers. 🛠️ What to change If you want AI services to access your public content, ask your website platform whether it can remove or narrow the wildcard block. A safer setup usually allows public content while continuing to block private areas, checkout pages, account pages, and internal search URLs. If the entire site is intentionally private, under construction, or restricted, you may leave the rule in place. In that case, the warning is informational and no change is required. 🏗️ Guidance for closed website builders Website builders often generate robots.txt automatically. You may not have access to edit the file directly, so do not follow instructions that refer to uploading robots.txt to a hosting root directory or changing it through WordPress plugins such as Yoast or Rank Math. - Simvoly: Check the site's SEO, visibility, and indexing settings. If Simvoly does not provide a robots.txt editor or crawler-specific controls, send Simvoly support the exact robots.txt URL and ask whether the wildcard rule can be narrowed to allow AI crawlers on public pages. - Wix: Review the site's SEO settings and robots.txt customization options available in the Wix dashboard. If the relevant rule is platform-controlled, ask Wix whether it can be changed for your site. - Squarespace: Review the site's SEO and page visibility settings. Squarespace may manage robots.txt automatically, so contact Squarespace through its available support process if a platform-generated rule blocks public content. - Shopify: Review the store's robots.txt customization options and theme or app settings. Keep protections for checkout, customer accounts, carts, and internal search, and change only broad rules that block public content unnecessarily. Platform features can change. If you cannot find a relevant setting, ask the builder to confirm whether the robots.txt file is editable and whether its wildcard rules are intentional. 💬 What to tell your platform provider Send the provider your robots.txt URL and ask: “Does this file block AI crawlers from all public pages? Can you allow AI crawlers while keeping private, checkout, account, cart, and internal search URLs blocked?” After any change, review the updated robots.txt file and rerun the Site Audit. Changes may take time to appear in crawler results. ✅ When no action is needed You may not need to make changes when the rules block only non-public or low-value areas, when you intentionally restrict AI access, or when the builder confirms the rules are required for its platform. Search Atlas cannot override a robots.txt file controlled by your website provider. 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.

What the Site Audit User Agent Setting Does

What the User Agent setting does The Site Audit User Agent setting controls how the Search Atlas crawler identifies itself to your website. In the support case used for this article, the Search Atlas option was described as identifying the crawler as Search Atlas Bot. The support response said the User Agent option is provided for the small chance that the Search Atlas Bot does not work well with a site. It also said the setting is not usually a major factor. Which User Agent should you use? If the Search Atlas Bot works normally with your site, you can keep the Search Atlas setting. If the Search Atlas crawler does not work well with your site, support suggested trying Google Chrome Desktop as an alternative. Contact support If you need help reviewing your crawl settings, click the chat icon in the bottom-right corner of the platform to start a live chat with a member of our team.

🔄 How to Initiate a Site Audit Recrawl and Manual Reprocess

📊 How to Download Your Site Audit Report

🔍 Overview If you want a clear list of the problems on your website and what to do about them, the Site Audit is the place to start. It scans your site, flags technical SEO issues, and suggests fixes. You can then download the results as a report to save, share with your team, or hand to a developer. This article walks you through running the audit, finding the issues and suggested fixes, and downloading the report. ✅ Before You Start - Make sure you are logged in to your Search Atlas account. - Confirm that the website you want to check has been added to your account as a project or site. - Have the full website address (domain) ready, for example yourwebsite.com. 🚀 Step 1: Run a Site Audit 1. Log in to the Search Atlas platform. 2. Select your project or website from the project selector, or add it if it is not there yet. 3. Open the Site Auditor tool from the main navigation menu. 4. Start a new audit for your website. If an audit has already run, you can use the latest results or start a fresh one. 5. Wait for the scan to finish. Smaller sites usually finish quickly, and larger sites with many pages take longer. You can leave the page and come back later. Tip: Menu names and button labels can vary slightly as we update the platform. If you do not see an exact label, look for the closest match. 🛠️ Step 2: Review Issues and Suggested Fixes When the audit completes, you will see an overview of your site's health and a list of detected issues. Here is what you will usually find: - Issue name: a short description of what was found, such as missing page titles, broken links, or slow-loading pages. - Severity or priority: how important the issue is, so you know what to fix first. - Affected pages: the specific pages where the issue appears. - Recommended fix: plain-language guidance on how to resolve the issue. Click an issue to see more detail, including the pages it affects and the suggested way to fix it. 📥 Step 3: Download the Report 1. Stay on the Site Audit results page for your website. 2. Look for an Export, Download, or Report option, usually near the top of the page. 3. Choose the format you want if you are given a choice. Available formats, such as PDF or spreadsheet, may vary. 4. Confirm the download. The file will be saved to your computer, usually in your Downloads folder. Open the file to check that it includes the issues and suggested fixes you want. If you need a shorter version, you can filter the audit results by issue type or priority before exporting, where filters are available. 💡 How to Use the Report - Start with high-priority issues. These usually have the biggest effect on your site's performance in search. - Share it with your team. Send the file to a developer, designer, or content writer so each person can handle the fixes in their area. - Track progress. Save each report and compare it with later audits to see how your site has improved. - Re-run the audit after making changes. This confirms the issues are resolved and updates your report. ❓ Common Questions - The audit is still running. Can I download the report? Wait until the scan finishes. The report can only include complete results. - I cannot find the download option. Make sure the audit has completed and you are on the results page for the correct website. Refreshing the page can also help. - The report looks empty or incomplete. Re-run the audit and check that your website address is entered correctly. Sites that block scanners may return limited results. - The download did not start. Check that your browser is not blocking downloads or pop-ups. Then try again, or try a different browser. - Can I get the report for a different website? Yes. Switch to that website using the project selector and run or open its audit. - Can the fixes be applied automatically? Some issues can be handled with Search Atlas tools such as OTTO SEO. Check the issue details for options available on your plan. 💬 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.

🔔 See Slack Status in Site Audit Alerts

Live Monitoring Alerts in Site Audit now show the state of your Slack connection. You can tell at a glance whether Slack is set up to receive your alerts, without having to guess or check elsewhere. ✨ What's New When you work with Live Monitoring Alerts in Site Audit, the page now displays your current Slack connection state. Previously, it was hard to tell whether Slack was linked to your alerts. Now you can see it directly where you manage them. - Clear visibility: See whether Slack is connected to your Live Monitoring Alerts. - Fewer missed notifications: Spot a disconnected Slack integration before you miss an important site issue alert. 🛠️ How to Use It 1. Open Site Audit for the project you want to monitor. 2. Go to the Live Monitoring Alerts section. 3. Check the Slack connection state shown there to confirm whether Slack is connected. 4. If Slack is not connected and you want alerts delivered there, reconnect your Slack integration. 📋 What to Expect - The Slack connection state reflects your current integration status each time you view the alerts. - This update only adds visibility. Your existing alert settings and thresholds are unchanged. - If you don't use Slack for alerts, you can keep using Live Monitoring Alerts as you did before. 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.

🔍 Exclude Tracking Pixels from Site Audit Alt Text Tasks

🔍 How to Re-Crawl an Existing Project

🔄 What Does Re-Crawling Do? When you add a website to Search Atlas, we crawl it to collect data about your pages, such as titles, headings, links, and technical settings. Your audit results and recommendations are based on that crawl. If you change your site later, those results can become out of date. Re-crawling an existing project scans your website again, so you see the current state of your pages and get fresh recommendations. You do not need to create a new project or delete your old one. 🗓️ When Should You Re-Crawl? A re-crawl is useful when your site has changed since the last scan. Common examples include: - You fixed issues from a previous audit and want to confirm they are resolved. - You published new pages or blog posts. - You changed page titles, meta descriptions, headings, or internal links. - You redesigned your site, moved pages, or changed your URL structure. - You updated technical settings, such as redirects, canonical tags, or robots rules. - The recommendations in your project look outdated or do not match your live site. 🛠️ How to Re-Crawl Your Website The exact labels may vary slightly as the platform is updated, but the process is generally the same: 1. Log in to your Search Atlas account. 2. Open the project (website) you want to refresh from your project list. 3. Go to the audit or site analysis section of that project. 4. Look for the option to run a new crawl, such as Re-crawl, Run Audit, or a refresh icon, and select it. 5. Confirm any prompts that appear. The crawl will start and show a progress or in-progress status. 6. Wait for the crawl to finish. When it is complete, your results and recommendations update automatically. You can keep working in the platform while the crawl runs, and you do not need to keep the page open. ⏱️ How Long Does It Take? Crawl time depends mostly on the size of your website. Small sites usually finish quickly, while sites with many pages take longer. Slow server responses or pages that block crawlers can also add time. If the status still shows as in progress, give it some time before starting another crawl, as repeated requests will not make it faster. 📊 What to Expect After the Crawl Once the re-crawl finishes, you should see: - Updated issue lists: Problems you fixed should no longer appear, and any new problems will be listed. - Refreshed recommendations: Suggestions will reflect your current content and settings. - Changes in scores or counts: Totals for pages, errors, and warnings may go up or down depending on what changed on your site. If a fix does not show as resolved, check that the change is live on your website and not just saved as a draft. Also clear any caching on your site or CDN, because a cached page can make the crawler see the old version. 💡 Tips for Better Results - Finish your edits first. Make your changes, publish them, and then re-crawl, so you do not scan a half-finished site. - Re-crawl after major updates. Run it after a batch of fixes rather than after every small edit. - Make sure the site is reachable. Crawls can fail or return incomplete data if the site is down, password-protected, or blocking crawlers. - Check your robots settings. If important pages are missing from the results, make sure they are not blocked from crawling. - Compare before and after. Note your key issues before you re-crawl so you can see what improved. ⚠️ Troubleshooting Common Problems - I cannot find a re-crawl option. Make sure you are inside the correct project and in the audit section. Some options may be unavailable while a crawl is already running. - The crawl seems stuck. Large websites can take longer. Wait a while and refresh the page before trying again. - Old issues are still showing. Confirm the fix is live, clear your site cache, and run the re-crawl again. - New pages are missing. Check that the pages are published, linked from other pages, and not blocked from crawlers. - The crawl failed. Check that your website is online and accessible, then try again. 💬 Need More Help? If you still cannot re-crawl your project or your recommendations do not update as expected, we are happy to help. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

🔍 Fixing Deactivated Sites in Publication Media

If your websites suddenly show as inactive in Publication Media, the cause is usually site verification. This article explains why sites get deactivated, how the verification meta tag works, and the steps to get your sites active again. ❓ Why Do My Sites Show as Inactive? Publication Media needs to confirm that you own or control each website before it can publish content there. It does this with a small verification meta tag placed in your site's code. A site can be marked inactive when: - The verification meta tag was never added to the site. - The meta tag was removed, for example during a theme change, a site redesign, or a plugin update. - The tag was added to the wrong place, such as the page body instead of the head section. - A caching or security plugin is hiding the tag from our system. - The website was moved, changed domains, or was temporarily offline when we checked. - The site connection was changed or removed in your account. If several sites went inactive at the same time, the cause is often something shared across them, such as a theme, a plugin, or a site-wide change. 🏷️ What Is the Verification Meta Tag? A meta tag is a short line of code that lives in the head section of your website's pages. It is invisible to visitors. It acts like a digital signature that tells us the site belongs to you. Without it, we cannot confirm ownership, so the site stays inactive. Each site has its own tag. A tag from one site will not verify a different site. 🛠️ How to Reactivate Your Sites 1. Open Publication Media in your Search Atlas account and find the site marked inactive. 2. Copy the verification meta tag shown for that site. 3. Log in to your website's admin area, such as WordPress, Wix, Shopify, or your hosting panel. 4. Paste the tag inside the head section of your homepage. Many platforms have a setting for adding custom head code. SEO plugins often have a field for site verification tags too. 5. Save your changes and clear any caching plugin or CDN cache so the tag is visible. 6. Return to Publication Media and select the option to verify or recheck the site. 7. Wait a moment and refresh the page to confirm the status changed to active. Repeat these steps for each inactive site. Every site needs its own tag. ✅ How to Check That the Tag Is Visible - Open your homepage in a browser, right-click, and choose View Page Source. - Search for the word meta and look for the verification line you copied. - Make sure it appears near the top, inside the head section. - If you cannot find it, the tag was not saved correctly or a cache is serving an older version of your page. 🧯 Common Problems and Fixes - The site still shows inactive after adding the tag: Clear all caches, then run verification again. Some hosts take a few minutes to show changes. - The tag keeps disappearing: A theme update or plugin may be overwriting your head code. Add the tag through a persistent setting, such as a child theme or a dedicated head-code plugin. - The site is password-protected or in maintenance mode: Our system cannot see the tag. Turn these off temporarily while verifying. - The domain or URL changed: Update the site details in your account and add the tag to the new address. - You do not have access to the site code: Ask your web developer or hosting provider to add the tag for you. 📝 What About Content Published Without a Tag? The verification tag is how we confirm that a site is connected to your account. If you see content on a site that you believe was published before verification was complete, or you did not expect it to be posted, please do not ignore it. Note the site address and the article title, then contact our team using the chat widget so we can review what happened and the site's status. 💡 Tips to Prevent Future Deactivation - Keep a copy of each site's verification tag in a safe place. - Recheck your tag after changing themes, updating plugins, or redesigning your site. - Tell your developer not to remove the verification tag when editing head code. - Review the status of your sites in Publication Media from time to time. - Avoid changing your domain or site structure without updating the site in your account. 💬 Still Need Help? If your sites are still inactive after adding the tag and running verification, our team can look at your account and check the status of each site. Please have your website addresses ready, and mention when the sites went inactive and whether any changes were made to them. 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 Website Verification Stuck on Meta Tag

🔍 What Is Meta Tag Verification? Before Search Atlas can connect to your website, we need to confirm that you own it. One common method is a meta tag: a short line of code that you add to the head section of your homepage. Our system looks for that line, and when it finds it, your site is verified. If verification seems stuck, it usually means our system cannot see the tag on your live homepage yet. This is almost always fixable in a few minutes. ⚠️ Why Verification Gets Stuck These are the most common causes: - The tag was not saved or published. The change was made in your website editor but never saved or published. - The tag is in the wrong place. It must sit inside the head section, not in the body of the page. - The tag was copied incorrectly. Missing characters, extra spaces, or curly quotes can break it. - An old tag is being used. If you generated a new tag, the old one will not work. - Caching is showing an old version of your site. Caching plugins, your hosting provider, or a CDN may still serve the page without the tag. - The tag was added to a different page or version of your domain. For example, it was added to an inner page, or to the www version when your homepage loads without www. - Our system cannot reach your site. Password protection, maintenance mode, firewalls, or security plugins can block the check. - Your site redirects the homepage. Some redirects send visitors to a different address that does not contain the tag. 🛠️ Step-by-Step: How to Fix It 1. Copy a fresh tag. Go back to the verification step in Search Atlas and copy the meta tag shown there. Copy the entire line without editing it. 2. Paste it into the head section of your homepage. Most website platforms have a setting for custom head code or an SEO plugin with a verification field. Paste the tag there, or directly after the opening head tag in your theme. 3. Save and publish your changes. Make sure the update is live, not just saved as a draft. 4. Clear your cache. Clear the cache in any caching plugin, your hosting dashboard, and your CDN if you use one. 5. Check that the tag is live. Open your homepage in a private browser window, right-click the page, and choose View Page Source. Search for the word meta and confirm that your tag appears near the top, inside the head section. 6. Return to Search Atlas and verify again. Click the verification button once. Wait a minute or two before trying again, since changes can take a short time to appear. ✅ Quick Checklist Before You Retry - The tag is the newest one shown in your Search Atlas account. - The tag appears in the page source of your live homepage. - The domain you entered in Search Atlas exactly matches the address that loads in your browser, including whether it uses www or not. - Your site is not in maintenance mode or behind a password. - No security tool or firewall is blocking automated visitors. - You have cleared all caches. 💡 Tips to Avoid Problems - If you use an SEO plugin or a site builder, use its built-in verification field instead of editing theme files. This keeps the tag in place after theme updates. - Do not remove the tag after verification. Keeping it in place helps avoid losing the connection later. - If you redesign or change themes, check that the tag is still present afterwards. - If someone else manages your website, send them the tag and ask them to confirm it is live in the head section of your homepage. 🧭 Still Stuck After Trying These Steps? If verification still does not complete, our team can take a closer look. To help us resolve it quickly, have these details ready: - Your website address exactly as entered in Search Atlas - The website platform you use, such as WordPress, Shopify, Wix, or a custom build - Whether you use a caching plugin, CDN, or security plugin - A screenshot of the page source showing the tag, or of any error message you see 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 Publisher Sites Show Inactive After Review

📌 Overview After you add a publisher site and verify ownership, our system runs an automated quality check to decide whether the site can go live. If it does not become active, that does not always mean the site is low quality. It may be rejected, still under review because we could not verify its metrics, or later marked inactive. This article explains the difference and what to do next. 🤖 How the Automated Review Works The automated check looks at several requirements together. Domain Authority must be at least 20, but that is only one requirement. A site can still be rejected or later marked inactive when another requirement, such as organic traffic, spam score, page quality, or price, does not pass. Signals the review may look at include: - Whether the site loads reliably and can be reached by our system - Whether the site’s verified organic traffic meets our minimum requirement. - The quality of the submitted page, including whether it loads, uses HTTPS, has enough visible content, and includes basic site links such as About, Contact, and Privacy. - Signs of spam, such as excessive outbound links or low-quality pages - Whether the site’s price is within the limit allowed for its Domain Authority. - Whether the submitted site contains the ownership verification tag and the submitted URL can be checked. ⚠️ Common Reasons a Site Shows Inactive - Site access issues: The site was temporarily down, slow, or blocked our review at the time it ran. Security tools, firewalls, and bot protection can cause this. - The submitted address could not be checked successfully. A timeout or error response can lower the page-quality result, while bot protection can prevent verification. Use the exact URL you submitted, including the correct https and www version. - Organic-traffic requirement not met: The site’s verified organic traffic is below our minimum, even if its Domain Authority passes. - Page-quality concerns: The submitted page has very little visible content, excessive external links or advertising, spam-like anchor text, or is missing basic site elements. - Other criteria not met: The site may meet the Domain Authority requirement but fail another requirement, such as organic traffic, spam score, page quality, or price. - Review still pending: If we cannot verify the site’s metrics, it shows as under review rather than active. We automatically retry that verification; once the required data is available, the site is approved or rejected. 🛠️ What to Check Before Requesting a Recheck Going through this list first helps us resolve your request faster. 1. Open the exact URL you submitted in a private browser window. Confirm it loads quickly and does not redirect somewhere unexpected. 2. Check that your firewall, security plugin, or hosting provider is not blocking automated visitors. 3. Check the site’s organic traffic in your analytics or SEO tools. Low verified organic traffic can prevent approval even when Domain Authority looks strong. 4. Review the submitted page for thin content, excessive advertising or external links, and spam-like links. Also confirm that its price is within the Domain Authority limit and that its ownership verification tag is still present. 5. Make sure the site has enough original, useful content that is clearly organized and relevant to its topic. 6. Remove or fix any broken pages, spammy links, or low-quality sections. 7. Confirm that the site details in your Search Atlas account match the live site. 🔄 How to Request a Recheck Once you have gone through the checklist and fixed any issues, ask for a recheck. To help us look into it quickly, include the following in your message: - The full URL of each site, exactly as submitted - The current status shown in the platform - The authority metrics you are referencing and where you found them - Any changes you made since the last review - Whether the site was recently down, migrated, or redesigned You can include several sites in one request. Sharing all the details up front avoids back-and-forth and reduces delays. ⏱️ What to Expect A recheck confirms whether the site now passes the automated review. If the site still does not qualify, our team can explain which requirement was not met so you know what to fix. Please note that a good authority score does not guarantee activation, because every site must pass all review checks. 💡 Tips to Avoid Inactive Status in the Future - Keep your site online and fast, and avoid changes during a review. - Use one consistent URL version and avoid unnecessary redirects. - Keep your content fresh, original, and focused on clear topics. - Do not block search engines or review tools unless needed. - Tell us about major changes such as domain moves or redesigns. 💬 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.

🛠️ Review Purchases, Request OTTO Help, Recrawl Audits

📌 What This Article Covers This guide answers three common questions from Search Atlas customers: - How do I see what I purchased and how much I spent this month? - How do I ask for an OTTO implementer to help with my site? - How do I run a fresh crawl of my site audit? 💳 How to Review Your Purchases and Monthly Spend If you need to confirm what you bought in a given month, such as September, start with your account's billing area. Your plan, add-ons, and one-time services are recorded there. 1. Log in to your Search Atlas account. 2. Open your account or profile menu. 3. Go to the Billing or Subscription section. 4. Open your invoices or payment history. 5. Filter or scroll to the month you want to review. Menu names can vary slightly depending on your plan and the current version of the platform. If you don't see one of the items above, look for similarly named options in your account settings. 🧮 How to Calculate Your Total for the Month To work out how much you spent in a month, follow these steps: 1. List every invoice or charge dated within the month, from the 1st through the last day. 2. Note each line item, such as your base subscription, add-ons, extra credits, or one-time services. 3. Add up the amounts. Check whether each one includes taxes. 4. Look for any refunds or credits and subtract them from the total. Tip: Charges are recorded on the date they were processed, which may differ from the date you started using a service. A renewal on September 30, for example, may appear in September even if the service period runs into October. 🧾 What You Might See on Your Invoice - Subscription charge: your recurring plan fee. - Add-ons: extra features or capacity added to your plan. - One-time services: items purchased individually, such as implementation help. - Taxes: shown separately when they apply. - Credits or refunds: shown as negative amounts or separate entries. 🤝 How to Request an OTTO Implementer OTTO SEO finds and recommends improvements for your site. If you would rather have a person help apply those changes, you can request an OTTO implementer. Availability and scope may depend on your plan or on what you have purchased. To make the request go smoothly, have these details ready: - The website or project name you want help with. - The OTTO recommendations or tasks you want implemented. - How your site is built, for example WordPress, Shopify, or another platform. - Any deadlines or priorities. Then send your request through the chat widget in the platform. Our team will confirm whether implementation is included in your plan and explain any next steps or costs before anything is charged. 🔄 How to Recrawl Your Site Audit A recrawl scans your site again so your audit reflects the latest changes. Run one after you fix issues, publish new pages, or have OTTO changes applied. 1. Open Site Audit from the platform menu. 2. Select the project or domain you want to scan. 3. Look for a Recrawl, Re-run, or Start New Audit button and select it. 4. Confirm any prompts. Some settings, such as page limits, may be adjustable. 5. Wait for the crawl to finish. Larger sites take longer. When the crawl finishes, review the updated health score and issue list. Fixed issues should disappear or move to a resolved state. 🔎 Troubleshooting Recrawl Problems - The recrawl button is unavailable: a crawl may already be running, or your plan may limit how often you can recrawl. Wait for the current crawl to finish. - Fixed issues still appear: changes may not be live yet, or caching may be serving an older version of the page. Clear your site cache and recrawl. - The crawl seems stuck: large sites can take a while. If there's no progress after a long time, contact our team. - Pages are missing: check whether your site blocks crawlers, for example through robots.txt rules, a firewall, or password protection. 💡 Best Practices - Review your billing history monthly so there are no surprises. - Save your invoices for bookkeeping or expense reporting. - Recrawl after every batch of fixes, not after each individual change. - Keep a list of OTTO tasks you want help with before you contact our team. 💬 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. Our team can help you confirm purchases and totals, request an OTTO implementer, or sort out a recrawl that isn't working.