Troubleshooting: Other Issues

🔄 Fix the D15 Validation Check Infinite Loop

🌍 Correct Domain Geographic Mapping

🌍 Why geographic mapping matters Search Atlas uses a domain’s geographic mapping to support location-based analysis, rankings, visibility data, and other regional results. If a domain is mapped to the wrong country, reports may reflect the wrong market. 🔍 Check the current mapping 1. Open the relevant domain or workspace in Search Atlas. 2. Review the country, market, or location shown for the domain. 3. Confirm that the selected country matches the business’s target market. For example, choose Australia instead of the United States when the domain targets Australia. ⚙️ Correct the domain mapping 1. Open the domain’s settings or configuration area. 2. Look for a field labelled Country, Market, Location, or Geographic mapping. 3. Select the correct country and save the change. 4. Refresh the page, then confirm that the updated country is displayed. Some accounts show these controls under a project, while others place them directly in the domain or workspace settings. If you do not see a Projects menu or a country dropdown, do not create a duplicate domain or project. The setting may be managed at a different account level. 🧭 If no country option is available First, confirm that you have access to edit the domain or workspace. Then check the domain’s configuration, setup, or business profile screens rather than only the main project view. Also verify that you are working in the correct workspace and that the domain is not being displayed through a read-only report. If the mapping still cannot be changed, provide the domain, the correct target country, the current mapping, and a screenshot of the available settings. This information helps the team update the correct record without creating duplicates. ✅ After changing the mapping - Confirm the correct country appears wherever the domain is used. - Review newly generated location-based reports for the correct market. - Allow time for existing reports or cached data to refresh. - Do not delete and recreate the domain unless instructed, as this can affect historical data and connected settings. 💬 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.

🛡️ Recover Your Site After a Spam Attack

🚨 What Is a Content Injection Attack? A content injection attack happens when a malicious actor gains access to your website and inserts unwanted content — such as gambling keywords, adult links, or spammy pages — directly into your site files, database, or CMS. These injections are designed to manipulate search rankings and redirect your visitors. Acting quickly is essential to protect your SEO authority and user trust. 🔍 Step 1: Identify the Scope of the Damage Before cleaning anything, understand exactly what was affected. - Search site:yourdomain.com casino OR gambling OR poker in Google to surface injected pages indexed by search engines. - Check your Google Search Console account under Security & Manual Actions for any manual penalties or security notices. - Review your server access logs for unusual file modifications or unfamiliar IP addresses during the suspected attack window. - Use Search Atlas's On-Page Audit (Left sidebar → Content → On-Page Audit) to scan your key pages for unexpected keyword signals or content anomalies. 🔒 Step 2: Secure the Entry Point Immediately Cleaning injected content without closing the vulnerability means attackers can re-inject. Complete these security steps first. 1. Change all admin, FTP, database, and hosting passwords immediately. 2. Revoke any unfamiliar user accounts or API keys from your CMS and hosting panel. 3. Update your CMS core, all plugins, and themes to their latest versions — outdated software is the most common entry point. 4. Install or reconfigure a Web Application Firewall (WAF) such as Cloudflare or Wordfence to block further intrusions. 5. Contact your hosting provider and ask them to confirm whether server-level files were modified. 🧹 Step 3: Remove Injected Content With the entry point secured, begin the cleanup process. 1. Restore from a clean backup if you have one dated before the attack. This is the fastest and safest option. 2. If no clean backup exists, manually audit your CMS pages, posts, templates, and widget areas for injected text, hidden links, or base64-encoded scripts. 3. Check your database for injected rows — look specifically in post content, meta fields, and options tables for gambling-related strings. 4. Scan your server file system for recently modified PHP or JavaScript files that were not part of a legitimate update. 5. Remove or replace every infected file and database entry. Do not simply edit over injected code — verify the entire block is clean. 📊 Step 4: Audit and Restore Your SEO Content Once the site is clean, use Search Atlas to assess SEO damage and rebuild content health. - Run an On-Page Audit (Left sidebar → Content → On-Page Audit) on your highest-traffic pages to confirm that injected keywords no longer appear in titles, meta descriptions, or body content. - Use the Meta Generator (Left sidebar → Content → Meta Generator) to rewrite any titles or descriptions that were corrupted or replaced by the attack. - Check your Topical Maps (Left sidebar → Content → Topical Maps) to identify whether the attack created topical dilution — content that now ranks your site for irrelevant gambling topics instead of your core subject matter. - Use the Content Planner (Left sidebar → Content → Content Planner) to prioritise rebuilding or strengthening the pages most harmed by the injection. 🚀 Step 5: Request Google Reconsideration (If Penalised) If Google issued a manual action against your site, you must formally request a review after cleanup is complete. 1. Log in to Google Search Console and navigate to Security & Manual Actions → Manual Actions. 2. Verify that all injected content has been removed and your site is fully secured. 3. Click Request Review and provide a clear summary of: what happened, what you removed, and what security measures you put in place. 4. Google typically responds within a few days to a few weeks. Monitor Search Console for the status update. 💡 Step 6: Prevent Future Attacks Strong ongoing hygiene reduces your risk of repeat incidents. - Schedule automated daily or weekly backups stored off-server so you always have a clean restore point. - Enable two-factor authentication (2FA) on all CMS, hosting, and domain registrar accounts. - Conduct regular security scans using a trusted malware scanner. - Audit user account permissions every quarter and remove anyone who no longer needs access. - Use Search Atlas's On-Page Audit monthly to spot unexpected content changes early, before they cause SEO damage. 🛠️ Need Additional 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 Outdated Site Metrics and Screenshots in Search Atlas

🧭 Why Is Search Atlas Showing Outdated Data? When a site has been recently updated or redesigned, Search Atlas may temporarily display older metrics and screenshots. This lag is normal and typically occurs for one or more of the following reasons: - The site has not been added to your Search Atlas dashboard. Without an active dashboard connection, Search Atlas cannot track or update your site's metrics in real time. - The OTTO pixel is not installed. The OTTO pixel is required to enable continuous data collection. Without it, Search Atlas relies on periodic external crawls rather than live site signals. - Google has not yet re-indexed the updated site. Site Explorer screenshots are sourced from Google's index. If Google has not recrawled your site since the update, the cached version will appear in Search Atlas. - Custom reports have not been refreshed. Metric snapshots in reports reflect the timeline you have configured. An outdated range will show historical data. The sections below walk you through each fix step by step. 📊 Step 1 — Add Your Site to the Dashboard Adding your site to the Search Atlas dashboard is the first step to enabling live metric tracking. 1. Log in to Search Atlas and go to Home (/home). 2. Locate the Add Website option and enter your full domain (for example, northamericanenclosures.us). 3. Follow the on-screen prompts to complete the setup. Search Atlas will begin pulling current data for the site once it is added. 4. Allow up to 24 hours for the initial metrics to populate after the site is added. If your site is already listed in the dashboard but metrics still appear stale, proceed to Step 2. ⚙️ Step 2 — Install the OTTO Pixel The OTTO pixel enables continuous, real-time data collection for your site. Without it, Search Atlas cannot track on-site changes as they happen. 1. From the left sidebar, navigate to OTTO SEO → SEO Automation (/seo-automation-v3). 2. Select your site and open the OTTO Setup section. 3. Copy the OTTO pixel snippet provided. 4. Paste the snippet into the <head> section of every page on your site, or install it via your tag manager (for example, Google Tag Manager). 5. Verify the installation by returning to the OTTO SEO dashboard and confirming the pixel status shows as Active. Important: The pixel must be present on your live, published site. Installing it only on staging or development environments will not trigger metric updates for the production domain. 📅 Step 3 — Update Your Custom Report Timeline If your reports are still showing old data after adding the site and installing the pixel, the report date range may need to be updated. 1. Open the report you want to refresh inside Search Atlas. 2. Locate the Date Range or Timeline selector within the report settings. 3. Set the range to include your desired start date — for example, from the date your site was updated to today. 4. Save and regenerate the report. The updated metrics will now reflect the selected period. Setting the correct timeline ensures you are viewing current performance data rather than historical snapshots from before your site changes. 🖼️ Step 4 — Understand the Site Explorer Screenshot Timeline Site Explorer displays a screenshot of your site sourced directly from Google's index. Search Atlas does not control when this image is updated — it depends entirely on when Google recrawls and re-indexes your site. - Typical refresh window: Screenshots update within 2 to 6 weeks after Google recrawls the site, though this varies based on your site's crawl frequency and domain authority. - Speed up the process: Submit your updated sitemap to Google Search Console and use the URL Inspection tool to request indexing for key pages. This signals to Google that your site has changed and encourages a faster recrawl. - No manual override: There is currently no option inside Search Atlas to force a screenshot refresh. The image will update automatically once Google has recrawled and cached the new version of your site. In the meantime, all other metrics — traffic, keywords, backlinks — will update in Search Atlas independently of the screenshot once Steps 1 through 3 are complete. ✅ Quick Checklist - Site added to dashboard? Go to Home (/home) and confirm your domain is listed. - OTTO pixel installed and active? Check OTTO SEO → SEO Automation (/seo-automation-v3) for a green Active status. - Report date range updated? Set the timeline to cover the period after your site changes. - Sitemap submitted to Google? Use Google Search Console to request faster recrawling for the screenshot to refresh. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix an Incorrect Wikipedia Link in Your Knowledge Graph

🔍 What This Article Covers Sometimes a Knowledge Graph entity may display an incorrect Wikipedia link or unrelated topic categories (such as references to a completely different industry or subject). If you have tried to remove these entries yourself and the change does not persist, this article explains the situation and how to get it resolved quickly. ⚠️ Known Limitation: Some Fields Cannot Be Self-Removed There is a known issue where certain Knowledge Graph field deletions — including Wikipedia URLs — appear to save in the interface but are not permanently removed from the underlying database. This means the incorrect information may reappear after you attempt to delete it. Because of this, manual removal by the Search Atlas team is currently required for these specific fields. 📋 Before You Contact Support To help the support team resolve your request as quickly as possible, gather the following information before reaching out: - Knowledge Graph entity ID or business name — for example, the domain or company name associated with the entity. - The incorrect field value — the exact Wikipedia URL or topic category that needs to be removed (e.g., a Wikipedia page for an unrelated subject such as mathematics or abstract algebra). - Confirmation that you have already attempted removal — let the team know if you tried deleting the entry and it reappeared, so they can skip straight to the manual fix. 🚀 How the Support Team Resolves This When you report an incorrect Wikipedia link or unrelated topic reference in your Knowledge Graph entity, a member of the Search Atlas team will: 1. Identify the specific Knowledge Graph entity using the ID or business name you provide. 2. Manually remove the incorrect Wikipedia URL and any associated unrelated topic references directly from the database. 3. Confirm with you once the removal is complete and the correct information is in place. This process is straightforward and is typically completed quickly once the support team has the details they need. 💡 Tips to Prevent Incorrect Data in Your Knowledge Graph - When adding or editing a Wikipedia URL in your Knowledge Graph, double-check that the linked page matches your actual business, brand, or topic — not a similarly named concept from an unrelated field. - If you notice incorrect topic categories appearing automatically, report them promptly. The longer incorrect data remains, the more it may influence AI-generated outputs tied to your entity. - After a manual fix has been confirmed by the support team, revisit the entity to verify the information looks correct on your end as well. 🙋 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.

🌐 Add a Subdomain as a Separate Search Atlas Project

🧭 Overview If your main domain (for example, yoursite.com) is already set up in Search Atlas with OTTO activated, and your WordPress blog lives on a subdomain (for example, blog.yoursite.com), you can add that subdomain as a completely separate project. This lets you track performance, run SEO workflows, and optionally activate OTTO independently for the subdomain — without affecting your main domain's configuration. ✅ Before You Begin - Confirm the subdomain is live and publicly accessible. - Know the full subdomain URL you want to add (for example, blog.yoursite.com). - Have admin access to your Search Atlas account. - Note that each project uses a slot from your plan's domain allowance. Check your current plan if you are unsure how many domains you have available. ➕ Step 1: Create a New Project for Your Subdomain 1. Log in to your Search Atlas account. 2. Locate the project or domain management area within the platform (typically accessible from the main navigation or dashboard). 3. Look for an option to add or create a new project. 4. In the domain field, enter your full subdomain URL — for example, blog.yoursite.com. Do not enter the main domain here. 5. Complete any additional setup fields such as project name, target country, and preferred search engine. 6. Confirm the new project to save your settings. Your subdomain now exists as its own independent project. Any data tracked, keywords added, or OTTO actions taken on this project will be separate from your main domain project. 🤖 Step 2: Activate OTTO on Your Subdomain (Optional) If you want OTTO to manage on-page SEO for your WordPress subdomain, you can activate it independently for that project. OTTO on the subdomain will not interfere with OTTO already running on your main domain. 1. Switch to your new subdomain project using the project selector at the top of the platform. 2. Navigate to the OTTO section from your dashboard. 3. Follow the standard OTTO activation steps for your subdomain project. 4. Once activated, OTTO will only apply changes and recommendations to the subdomain project. Important: Each domain or subdomain with OTTO activated counts as a separate OTTO seat. If your plan includes a limited number of OTTO activations, make sure you have an available seat before proceeding. 📊 Step 3: Set Up Tracking for Your Subdomain Once your subdomain project is created, configure tracking to start collecting meaningful data. - Rank Tracker: Navigate to the Rank Tracker section within your subdomain project and add the keywords you want to monitor for the subdomain specifically. - Site Metrics: Ensure your subdomain project is selected so that all site metrics data is collected and displayed separately from your main domain. ❓ If You're Not Sure Where to Start If you are unsure which area of the platform to use for adding a new project or domain, or if you encounter any unexpected behavior when trying to set up your subdomain, our support team can walk you through the exact steps for your account and plan. When reaching out, please have the following ready: - Your main domain name already set up in Search Atlas - The full subdomain URL you want to add as a separate project - Your current plan details (so the team can confirm domain slot availability) - Any error messages or unexpected behavior you 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 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.