Security & Trust

🔒 Secure Your Account After Unexpected Changes

🔍 What unexpected changes may mean Unfamiliar projects, saved settings, or a changed logo can have several causes. Someone may have accessed your account, a team member may have made the change, or a temporary display or account-data issue may have shown incorrect information. Do not assume that your data is permanently lost. First, secure access and collect details about what changed. 🛡️ Secure your account immediately 1. Change your password to a new, unique password that you do not use elsewhere. 2. Review team access. Open the account menu in the top-right corner, select Team Members, and check for unfamiliar users or roles. 3. Remove unknown access if your permissions allow it. If you cannot remove a user, record their name and role. 4. Sign out of other sessions if this option is available in your account security settings. 5. Secure the email account associated with Search Atlas, including its password and multi-factor authentication settings. 📋 Check what changed Record the project names, logo appearance, approximate time of each change, and the page where you noticed the issue. Take screenshots before making further edits when possible. - Check whether the unfamiliar projects appear in your normal workspace or under a different team. - Ask authorized team members whether they created or edited the projects. - Refresh the page, sign out, and sign back in to check whether the display changes. - For logo issues, check both the account dashboard and any white-label or agency-facing pages. 🖼️ If your logo was changed Confirm that the logo is incorrect across more than one page. A cached image, a white-label setting, or a temporary display problem can sometimes show an outdated or incorrect logo. After securing the account, upload the intended logo again if you have permission to manage branding. If the upload fails or the wrong logo continues to appear, keep the screenshot and page URL for investigation. ⚠️ Signs of possible unauthorized access - Projects or settings changed without approval. - Unknown team members or permission changes. - Changes that return after you correct them. - Activity occurring while your team confirms that nobody made the change. - Unexpected password-reset or login notifications. If you see these signs, avoid sharing your password and complete the security steps above before continuing to edit account settings. 💬 Contact support When contacting support, include the affected workspace or project names, screenshots, approximate timestamps, the account email domain, and the steps you already completed. Do not include passwords, authentication codes, or other sensitive credentials. If you need further assistance, open 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 External API 403 Scope Errors Fast

🔍 What This Article Covers If every call to the Search Atlas External API — including the token/validate endpoint — returns an HTTP 403 error with the message "Invalid scope provided. Check API Key permissions on your Press Releases account!", your API key is missing the press-release scope. This article explains what causes this error and the exact steps to resolve it. ⚠️ Understanding the 403 Error The 403 error means the API key you are using does not have permission to access the Press Releases (External API) scope. This is not a network issue or a bug in your integration code — it is a permissions configuration issue on your Search Atlas account. Until the correct scope is enabled, every API call, regardless of endpoint, will be rejected with this message. Common situations where this happens: - You recently generated a new API key but did not assign all required scopes. - Your account plan was changed and certain scopes were reset. - A team member created the API key without enabling the press-release permission. - You are using an older hardcoded token that no longer has the correct permissions. 🛠️ How to Fix the Scope Error Follow these steps to check and update your API key permissions inside Search Atlas. 1. Log in to your Search Atlas account. 2. Click your profile icon or account name in the top-right corner of the platform. 3. Navigate to Account Settings and select the API Keys or Integrations section. 4. Locate the API key you are using for Signal Genesys or your External API integration. 5. Click Edit or Manage Permissions on that key. 6. Ensure the press-release scope (also labeled External API in some views) is toggled on. 7. Save your changes. 8. Re-run your token/validate call to confirm the 403 error is resolved. Important: If you do not see an option to enable the press-release scope, your current account plan may not include External API access. Contact our team using the chat widget to verify your plan includes this feature. 🔑 Best Practices for API Key Setup To avoid scope errors in the future, follow these recommendations whenever you create or rotate API keys: - Always review the full list of scopes before saving a new API key. - Enable only the scopes your integration actually needs — but do not accidentally leave required scopes unchecked. - Avoid hardcoding API tokens directly in your application code. Use environment variables or a secrets manager so tokens can be rotated without a code deployment. - After rotating a key, immediately run a validation call (token/validate) to confirm the new key has the correct permissions before pushing to production. - Document which scopes each integration requires so your team can replicate the setup consistently. 📋 Signal Genesys Integration Checklist If you are connecting Signal Genesys to Search Atlas via the External API, confirm all of the following before testing: - Your API key has the press-release scope enabled. - You are using the correct base URL and OAuth client credentials flow (not a legacy hardcoded token). - Environment variables in Signal Genesys are up to date with the current key and endpoint values. - You have tested the token/validate endpoint independently before making other API calls. 💬 Still Seeing the 403 Error? If you have followed all the steps above and the error persists, it is possible that the press-release scope needs to be enabled on your account at the platform level by our team. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔄 How to Remove and Replace a Team Member

This article explains how to remove a team member from your Search Atlas account and invite a replacement. Whether you are offboarding a colleague or updating your team's access, the steps below walk you through the full process and show you how to confirm the changes took effect. 🛠️ Step-by-Step 1. Log in to your Search Atlas account and open your account or workspace settings. 2. Navigate to the team or users section within your settings. 3. Locate the team member you want to remove. Look for an options menu, action button, or kebab icon (⋮) next to their name or email address. 4. Select the option to remove, delete, or revoke access for that user. If prompted, confirm the action in any dialog box that appears. 5. Once the removal is confirmed, look for an option to invite or add a new team member — this is typically a button near the top of the team list. 6. Enter the new team member's email address, assign them an appropriate role or permission level, and send the invitation. 7. Ask the new team member to check their inbox (including their spam or junk folder) for the invitation email and complete the sign-up or acceptance steps. ✅ How to Confirm It Worked 1. Return to your team or users settings page and refresh the page. 2. Confirm that the removed team member's name or email address no longer appears in the list. 3. Confirm that the new team member's name or email address does appear in the list, either as active or invited. 4. Once they accept the invite, their status should update from Invited to Active (or equivalent), confirming they now have full access. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

📊 Single-Site vs. Growth Plan: Complete Comparison Guide

🗺️ Overview If you are managing more than one client or scaling your agency, this article covers what to consider when comparing the Single-Site and Growth plans, and how to upgrade your plan and connect a Google Search Console (GSC) property to your account. 📋 Plan Comparison: Single-Site vs. Growth The two plans are designed for different stages of growth. Single-Site is built for managing a single website or client, while Growth is designed for users who need to manage multiple websites or clients under one account. If you are unsure which plan is right for your situation, our support team can review your account and help you decide. 🏢 Who Should Upgrade to Growth? Consider upgrading to the Growth plan if any of the following apply: - You are onboarding a second client and need a separate project and GSC connection for them. - You have outgrown the limitations of the Single-Site plan and need expanded capacity. - Your team needs to collaborate within the platform across multiple client accounts. If you are currently on Single-Site and managing only one client with no immediate plans to grow, the Single-Site plan may continue to meet your needs. ⬆️ How to Upgrade from Single-Site to Growth To upgrade your plan, navigate to the Billing page from the top-right avatar menu in your Search Atlas account. From there, locate the Growth plan option and follow the on-screen prompts to complete your upgrade. 🔗 How to Connect Google Search Console After Upgrading Once your plan is upgraded, go to the integrations or project settings area of your Search Atlas account to connect a Google Search Console property. Follow the prompts to authorize your Google account and select the GSC property you want to associate with your project. If you need to connect a GSC property for an additional client, repeat this process within their respective project. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

📋 Business Registration Fields: ISO 6523, Tax ID, VAT ID

📋 Overview Search Atlas collects certain business registration details to support accurate billing, invoicing, and compliance. Three fields that sometimes cause confusion are the ISO 6523 Code, Tax ID, and VAT ID. This article explains where these fields are located in the platform and how to handle them. 🗺️ Where to Find These Fields The Tax ID, VAT ID, and ISO 6523 Code fields are located within your account's billing or business information settings. Log in to your Search Atlas account and navigate to your billing or account settings area to locate them. If you are having trouble finding these fields, our support team can point you to the exact location in your account. 🔍 What Each Field Is For - Tax ID: A government-issued tax identification number for your business or organisation. - VAT ID: A Value Added Tax identification number for businesses registered for VAT. - ISO 6523 Code: A standardised code used to identify organisations in electronic business transactions. ✅ Completing the Fields Enter the relevant values for your business in each field. If you do not have a value for a particular field — for example, if your business is not VAT-registered or does not use an ISO 6523 identifier — leave that field blank rather than entering a placeholder. If you are unsure what to enter for any of these fields, contact your finance or compliance team, or reach out to our support team for guidance. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔒 Responding to a Security Incident on Your Website

🔍 Overview If your website experiences unexpected behaviour — broken pages, unauthorised changes, or sudden downtime — it can be easy to assume a recently installed plugin or tool is responsible. However, many incidents are actually caused by compromised credentials, such as a weak or reused password belonging to a team member. This article explains how to investigate the true root cause of a website issue and how to strengthen your account security going forward. 🧩 Common Causes That Mimic Plugin Issues Before concluding that a plugin like OTTO SEO is responsible for a site problem, consider these frequent alternative causes: - Weak or reused passwords: A team member account with a simple password can be brute-forced or leaked in a third-party data breach, giving attackers access to your site or platform. - Unauthorised login: An attacker who gains access using stolen credentials can make changes that look like software malfunction. - Shared credentials: Multiple people using the same login makes it difficult to trace the source of a change and increases exposure if one device is compromised. - Outdated WordPress roles or permissions: Overly broad user roles can allow accidental or malicious changes by lower-trust team members. 🛠️ How to Investigate the Root Cause 1. Check your activity logs. In WordPress, install or use an existing activity log plugin to review which user account made recent changes and at what time. 2. Review user accounts. Go to WordPress Admin → Users and look for unfamiliar accounts or accounts with Administrator roles that should not have them. 3. Inspect recent logins. Some security plugins (e.g. Wordfence, iThemes Security) log login attempts and flag suspicious IP addresses or failed login spikes. 4. Check Search Atlas activity. Log in to your Search Atlas dashboard and review any recent project changes or OTTO SEO actions to confirm whether the platform was involved. 5. Isolate the timeline. Compare when the issue first appeared with the timestamps of any plugin updates, user logins, or password changes to narrow down the cause. 🔐 Steps to Secure Your Account After an Incident Once you have identified the root cause, take immediate action to close any security gaps: 1. Reset the compromised password immediately. Use a strong, unique password of at least 16 characters combining uppercase letters, lowercase letters, numbers, and symbols. 2. Enable two-factor authentication (2FA). Turn on 2FA for WordPress, Search Atlas, and any other tools your team uses. This adds a critical second layer of protection. 3. Audit all team member accounts. Remove any accounts that are no longer needed and downgrade roles to the minimum permission level required for each person's work. 4. Force a password reset for all users. If there is any doubt about the extent of the compromise, reset passwords for every team member account. 5. Scan for malware. Run a full malware scan using a trusted security plugin to confirm no malicious code was injected during the incident. 6. Update all plugins and themes. Ensure your WordPress installation, all plugins, and all themes are running their latest versions to eliminate known vulnerabilities. ✅ Best Practices to Prevent Future Incidents - Use a password manager to generate and store unique passwords for every account. - Never share login credentials between team members — each person should have their own account. - Schedule a quarterly review of user roles and remove inactive accounts promptly. - Enable login notifications so you are alerted whenever a new device or location accesses your account. - Keep a record of any changes made to your site so you can quickly isolate the cause of future issues. 💬 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.

🔑 MetaSync MCP Server JWT Security: Token Validation, Secret Rotation & Access Hardening

The MetaSync MCP server's JWT validation bypass (WP-285) has been patched. Any site running MetaSync MCP on WordPress should rotate its JWT secret immediately — this invalidates all pre-patch tokens, including any that exploited the bypass. 📌 Scope: This article applies only to the MetaSync MCP server WordPress plugin. If you use the Search Atlas hosted MCP server at mcp.searchatlas.com, this guidance does not apply — refer to the hosted MCP server documentation instead. ⚠️ What the Vulnerability Was and Why It Matters The MetaSync MCP server's verify_jwt_token() function applied isset() checks to the exp (expiry) and iss (issuer) JWT claims. Because isset() only tests whether a field exists — not whether it holds a valid value — a JWT crafted without those claims was accepted if its signature was valid against the stored secret. If your secret has never been exposed, the practical risk is lower, but rotation is still recommended as a precaution and is required to revoke any tokens already in circulation. Where the bypass was exploited, the resulting token never expired and carried no issuer binding, granting permanent access to all authenticated MCP server endpoints — including endpoints exposing WordPress post and metadata read/write, plugin configuration, and any other capability the MCP server registers for authenticated callers. WP-285 closes this by requiring both claims to be present and valid on every incoming token. The patch was released on 2024-11-14 as part of MetaSync MCP plugin version 1.4.2. Existing tokens issued before the patch are unaffected by the code fix alone — rotating the JWT secret is what revokes them. 🔍 How to Determine Whether Your Site Is Affected Check all three conditions: - You run the MetaSync MCP server plugin on a WordPress site. - You have not rotated the JWT secret stored in wp_options since the WP-285 patch was applied (plugin version 1.4.2, released 2024-11-14). - Your site issued JWT tokens to external clients, API integrations, or automation tools before the patch date. To check when a specific token was issued, decode it (for example, paste it at jwt.io) and read the iat (issued-at) claim. If iat is earlier than 2024-11-14, the token predates the patch. If all three are true, treat your current tokens as potentially compromised and rotate the secret before taking any other action. 🔑 How to Rotate the JWT Secret in wp_options Rotating the JWT secret immediately invalidates every previously issued token. You can rotate via the WordPress admin UI or WP-CLI. Option A — WordPress admin: 1. Navigate to wp-admin → Search Atlas → Settings (MetaSync MCP). 2. Locate the JWT Secret field and click Regenerate. 3. Click Save Changes. 4. Re-issue new tokens from the same settings panel to each external client and API integration that needs continued access. Option B — WP-CLI: 1. SSH into your WordPress server or open a terminal with WP-CLI access. 2. Identify the exact wp_options key MetaSync MCP uses for its JWT secret. Check your plugin documentation or run: wp option list --search="*jwt*" --fields=option_name 3. Generate a cryptographically random replacement secret and write it to wp_options: wp option update <your_jwt_secret_key> "$(openssl rand -hex 32)" 4. Confirm success — WP-CLI outputs Success: Updated '<your_jwt_secret_key>' option. All tokens signed with the old secret are now invalid. Re-issue new tokens to every legitimate client that needs continued access before they attempt another request. 📋 After Rotating: Post-Rotation Checklist Rotation will cause every active integration to start failing authentication until it receives a freshly signed token. Work through the following immediately after the secret is updated: 1. Re-issue tokens to all connected clients. This includes external API consumers, automation tools, CI jobs, and any internal services that authenticate to the MCP server. 2. Verify integrations are reconnected and healthy. Trigger a known-good request from each client and confirm it returns HTTP 200. Watch your error logs for residual 401 responses, which indicate a client that hasn't been updated yet. 3. Revoke or delete any tokens whose origin is unknown. If you find token records or active sessions you cannot tie to a legitimate client, do not re-issue them — remove them entirely. Note for Search Atlas AI Agent users: If you use Search Atlas AI Agent integrations alongside MetaSync MCP, be aware that SA JWT tokens now also validate active subscription status (shipped via AIAGENT-2012). Tokens issued for inactive or lapsed Search Atlas accounts will be rejected independently of this patch, which can look like a rotation failure but is unrelated. Troubleshooting silent auth failures: If authentication fails silently after rotating the JWT secret, check whether your WordPress or Search Atlas account has duplicate usernames prefixed with searchatlas_. This is a known issue (LPS-1114) and may require deduplication before re-authentication succeeds. 🧹 How to Audit Token Usage Before and After the Patch After rotating the secret, identify which clients held tokens and confirm no unauthorized access occurred during the exposure window. 1. Review your web server access logs for requests to MetaSync MCP endpoints that carried a JWT Authorization: Bearer header. Filter to the date range before the WP-285 patch was applied. 2. Check your WordPress authentication logs (if enabled via a security plugin) for any MCP API calls that authenticated successfully during that window. 3. For each identified client, determine whether the access was legitimate. If you find unexplained API calls, treat the site as potentially compromised and engage your WordPress security team. 4. Contact every legitimate client and provide a freshly signed token issued against the new secret. Once all legitimate clients hold new tokens, no pre-patch token — including any that exploited the bypass — can authenticate against your MCP server. 🛡️ JWT Hardening Settings to Apply After Patching The WP-285 patch enforces exp and iss claim validation by default. Apply these additional controls to reduce future risk: - Set a short token lifetime. Configure token expiry (exp) to 3,600 seconds (1 hour) or the shortest interval your integrations can tolerate. Never issue tokens with an unlimited or multi-year lifetime. - Verify the issuer value. Ensure the iss claim MetaSync MCP embeds in tokens matches your site's canonical URL. The patch now rejects any token whose iss does not match the configured value exactly. - Apply least-privilege token scope. Issue tokens with only the WordPress capabilities the client actually needs. Avoid tokens with full administrator scope for read-only integrations. - Rotate the secret on a schedule. Rotate your JWT secret at least every 90 days, or immediately after any suspected credential exposure. These controls ensure every active token has a bounded lifetime, a verified origin, and only the access level it requires. ✅ How to Verify the WP-285 Patch Is Active on Your Installation Confirm the fix is live by testing the two previously exploitable token shapes against your MetaSync MCP endpoint. 1. Craft a JWT that omits the exp claim, signed with your current (rotated) secret. Use jwt.io or a local JWT library. 2. Send a request to your MetaSync MCP endpoint with that token as the Authorization: Bearer header. The server must return HTTP 401 Unauthorized. 3. Repeat with a token that omits the iss claim only. The server must again return HTTP 401. 4. Send a correctly formed token — with valid exp and iss claims — and confirm the server returns HTTP 200 and processes the request normally. A 401 on both malformed tokens and a 200 on the valid token confirms the WP-285 patch is functioning correctly on your installation. 🎯 You have now revoked all pre-patch tokens, rotated your JWT secret, and hardened your MetaSync MCP server's token policy. For diagnosing MCP connection and configuration errors more broadly, see Understanding MCP Errors & How to Fix Them.

🔒 Search Atlas Security Disclosure Program Explained

🛡️ Overview of Our Security Program Search Atlas takes the security of our platform and customer data seriously. We welcome reports from security researchers, customers, and the broader community who discover potential vulnerabilities in our systems. This article outlines our current policy for responsible disclosure and answers common questions about our security program. 🐛 Do We Have a Bug Bounty Program? At this time, Search Atlas does not operate a formal, public bug bounty program with monetary rewards. We do not currently partner with third-party bug bounty platforms such as HackerOne or Bugcrowd. However, we do have a responsible disclosure policy that allows security researchers and users to report vulnerabilities directly to our team for review and remediation. 📋 What Is Responsible Disclosure? Responsible disclosure is a process where a researcher or user who discovers a security vulnerability privately reports it to the affected organization before making it public. This gives the organization time to investigate and fix the issue, protecting users from potential exploitation during the remediation window. We ask that anyone who discovers a potential security issue in Search Atlas: - Report the issue privately and promptly rather than disclosing it publicly. - Provide enough detail for our team to reproduce and understand the vulnerability. - Avoid accessing, modifying, or deleting data that does not belong to you. - Refrain from performing denial-of-service attacks, social engineering, or phishing against our team or users. - Allow our team reasonable time to investigate and address the issue before any public disclosure. 📬 How to Report a Security Vulnerability To report a security vulnerability, please contact our support team directly through the Search Atlas platform. Include the following details in your report: 1. Description: A clear summary of the vulnerability and the potential impact. 2. Steps to reproduce: A step-by-step walkthrough that allows our team to replicate the issue. 3. Environment details: The browser, device, or account type involved, if relevant. 4. Supporting evidence: Screenshots, screen recordings, or logs that illustrate the issue. Our team will review your report and follow up with you as the investigation progresses. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Fake DMCA Copyright Scam: What to Do

Some Search Atlas users have reported receiving fake DMCA (Digital Millennium Copyright Act) copyright infringement notices falsely claiming their MetaSync plugin activity has violated intellectual property law. These emails are phishing scams designed to steal your credentials or payment information — not legitimate legal notices. 🚨 How to Identify a Fake DMCA Notice Legitimate DMCA takedown requests are sent to site owners or hosting providers, not to end users of a SaaS platform. A fake notice targeting your account typically includes: - Urgent language threatening account suspension or legal action within 24–48 hours - A link to "resolve" the violation or "pay a fine" - Generic sender addresses not from an official Search Atlas domain - Requests for your Search Atlas login credentials or payment details - Attachments or forms asking you to "verify" your account - References to the MetaSync plugin by name and to specific URLs on your site, used to make the notice appear targeted and credible ✅ What to Do If You Receive This Email 1. Do not click any links in the email, even if they appear to lead to official-looking websites. 2. Do not pay any fees, fines, or charges mentioned in the notice. 3. Do not share your Search Atlas username, password, or billing information. 4. Log in to your Search Atlas dashboard directly by typing the URL manually in your browser. Any legitimate account notices will appear inside the platform. 5. Forward the suspicious email to your IT or security team, and report it as phishing in your email client. 6. Contact Search Atlas support via live chat to confirm whether any action is actually required on your account. 🔒 Why Plugin Users Are Targeted Attackers target users of plugins and integrations because these tools involve third-party permissions and API connections, making users more likely to believe a compliance notice is real. Search Atlas will never ask you to pay a DMCA fine via email or request your credentials through an external link. 🛡️ Protecting Your Account - Enable two-factor authentication (2FA) on your Search Atlas account if available. - Use a unique, strong password not shared with other services. - Periodically review connected integrations under Settings > Integrations in your dashboard to ensure no unauthorized connections exist. 💬 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.

🔒 Responding to Unauthorized Account Activity

🔍 Overview If you notice projects, users, or changes in your account that you did not initiate, treat it as a potential security incident and act quickly. This article walks you through how to identify suspicious activity, secure your account immediately, and escalate to our team for investigation. ⚠️ Signs of Unauthorized Account Activity Common indicators that your account may have been accessed without your permission include: - Projects appearing in your account that you or your team did not create - New team members or users you do not recognize - Changes to settings, integrations, or connected properties you did not make - Unexpected email notifications about account changes - Activity in connected tools (such as Google Search Console) that you did not trigger 🛠️ Step 1 — Secure Your Account Immediately Before investigating, take these steps to limit further unauthorized access: 1. Change your password immediately. Use a strong, unique password that you have not used on any other platform. 2. Enable two-factor authentication (2FA) if it is not already active on your account. 3. Review active team members. Go to the top-right avatar menu and select Team Members (or navigate to /settings). Remove any users you do not recognize or did not invite. 4. Revoke any API keys that may have been issued without your knowledge, if accessible in your account settings. 5. Sign out of all active sessions to force any unauthorized sessions to end. 🔎 Step 2 — Identify What Changed After securing your account, document the suspicious activity so our team can investigate effectively: - Note the names and dates of any projects you did not create - Record any user accounts or email addresses that appear unfamiliar - Screenshot any settings or integrations that look altered - Check your email inbox for any Search Atlas notifications you did not expect, including invitations sent to unknown recipients The more detail you can provide, the faster our team can trace the source of the activity and take action. 👥 Step 3 — Audit Your Team Members A common source of unexpected account activity is an unrecognized user with access to your workspace. To review and manage your team: 1. Click your avatar in the top-right corner of the platform. 2. Select Team Members from the dropdown menu, or go directly to /settings. 3. Review the full list of users, their roles, and access levels. 4. Remove any user you did not invite or no longer recognize by selecting the appropriate option next to their name. If you find a user with view-only access that you did not invite, remove them immediately and report this to our support team for further investigation. 🚨 Step 4 — Report the Incident to Our Team Once you have secured your account and documented the suspicious changes, contact our team right away. We can investigate the origin of the activity, review access logs, and take additional protective action on our end. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. When you reach our team, please share: - A description of what you observed and when you first noticed it - Screenshots or names of unrecognized projects, users, or changes - Whether you have already removed any unauthorized users or changed your credentials 💡 Best Practices to Prevent Unauthorized Access Reduce the risk of future incidents by following these security best practices: - Use a unique, strong password for your Search Atlas account — do not reuse passwords from other services. - Enable two-factor authentication on your account and encourage all team members to do the same. - Audit your team members regularly, especially after offboarding employees or ending agency relationships. - Be cautious with API keys — only share them with trusted integrations and revoke any that are no longer needed. - Monitor account notifications — unexpected emails about your account are often the first sign of unauthorized access.

🛡️ Metasync Plugin Script Injection Security Issue

🔍 What Happened A security issue was identified in the Metasync plugin's server-side rendering (SSR) output. In affected cases, malicious content — including scripts disguised as Google Tag Manager (GTM) — appeared in a site's live HTML output while the Metasync plugin was active, and disappeared when the plugin was deactivated. This issue was not caused by your configuration or content. It originates from how the plugin constructs and renders output on the server side. Our engineering team is aware of the issue and is actively working on a fix. ⚠️ Who Is Affected - WordPress sites running the Metasync plugin with server-side rendering enabled - Sites where injected output appeared only when the Metasync plugin was active — and disappeared when it was deactivated If your site showed a suspicious GTM-like script in its HTML source exclusively while Metasync was active, this vulnerability is the most likely cause. 🛠️ What Is Being Done Our engineering team has confirmed the issue and a fix is in active development. We will update this article as fixes are released. Watch your platform notifications for plugin update announcements. ✅ Immediate Steps to Take 1. Deactivate the Metasync plugin temporarily if you have not already done so. This stops the injection vector while the patched version is being released. 2. Scan your site's live HTML source for any unexpected <script> tags, especially those referencing GTM-like IDs or external domains you do not recognise. 3. Check your Google Tag Manager account to confirm all tags present on your site were added by your team. 4. Review your server and CMS access logs for the period when the plugin was active to identify any unusual activity. 5. Install the updated version of the Metasync plugin as soon as it is available and announced via platform notifications. 📋 When Escalating to Support Because this issue requires a backend investigation, please have the following ready when you contact our team: - Your WordPress site URL - The exact script or code snippet you observed in your HTML source - The date and time range when the injection was first noticed - Confirmation of whether deactivating the Metasync plugin removed the injected content If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

⚡ Respond to Unauthorized Account Activity Fast

What This Means and Why It Matters If you notice projects in your Search Atlas account that you or your team did not create, this is a serious security concern. Unauthorized projects can indicate that your account credentials have been compromised, that a former team member still has access, or that account sessions are being shared unintentionally. Act quickly — the steps below will help you contain the issue and prepare the information our team needs to investigate. Step 1 — Audit Your Team Members Start by reviewing who currently has access to your account. Look through your account's user or team management settings for anyone you do not recognise, former employees, or accounts with unexpected permission levels. Remove access for any user who should not have it, and re-invite legitimate users with fresh invitations if needed. Even one unfamiliar user account can be the entry point for unauthorized activity. If in doubt, remove access and re-invite legitimate users. Step 2 — Change Your Password Immediately If you suspect your credentials have been exposed, reset your password right away through your account settings. Set a new, strong password that is unique to Search Atlas — do not reuse passwords from other services. If your organisation uses shared login credentials, ask all legitimate team members to update their passwords and switch to individual accounts where possible. Step 3 — Document the Unauthorized Projects Before removing anything, collect evidence so our team can investigate effectively. - Take screenshots of any projects you did not create, including project names, creation dates, and any associated URLs or keywords. - Note the approximate date when you first noticed the activity. - Record any other unusual behaviour, such as unexpected changes to existing projects, billing anomalies, or unfamiliar API usage. Do not delete the unauthorized projects yet — preserving them allows our security team to trace the source of the activity. Step 4 — Revoke Unrecognised API Keys and Integrations Unauthorized access can sometimes originate from an exposed API key or a connected third-party tool. Review any active API keys linked to your account and revoke any that you do not recognise or no longer use. Check connected integrations and remove any unauthorised connections. If your credentials were stored in a shared document, spreadsheet, or code repository, remove them immediately. Step 5 — Escalate to Our Security Team Because investigating unauthorized account activity requires backend access to audit logs and session data, our team will need to take action on your behalf. To help us investigate as quickly as possible, please have the following ready when you contact us: - Your account email address and the name of the affected workspace or organisation. - Screenshots and notes collected in Step 3. - The names of any users removed in Step 1 and any API keys revoked in Step 4. - The approximate date you first noticed the unauthorized activity. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔒 GDPR Account Deletion and Email Suppression Guide

🔍 Overview If you have submitted a GDPR deletion request and are still receiving emails from Search Atlas, this article explains what to expect, why delays can occur, and how to confirm that your account and data have been fully removed. Understanding each stage will help you confirm that your data has been fully removed and that email suppression is active. 📋 What Happens When You Submit a GDPR Deletion Request When a valid GDPR account deletion request is received, Search Atlas initiates the following steps: 1. Account deactivation — Your account access is disabled immediately. 2. Data removal — Personal data, projects, and associated records are deleted from our primary systems and queued for removal from all related services. 3. Email suppression — Your email address is added to a suppression list to prevent future marketing and transactional emails. 4. Post-processing confirmation — A background process verifies that all data has been cleared across every connected service. In most cases this process completes within 30 days of your request, in line with GDPR requirements. However, some customers have experienced delays due to post-processing issues that our engineering team actively monitors and resolves. ⚠️ Why You May Still Receive Emails After a Deletion Request There are a few known reasons why emails may arrive after a deletion request has been submitted: - Post-processing delay — In rare cases, the background process that finalises data removal and email suppression can encounter an error. This does not mean your data has not been deleted; it means the suppression step needs to be re-triggered manually by our team. - Link scanner interference — Some corporate email security tools automatically follow every link in an email, including unsubscribe links, before you even open the message. This can trigger an unsubscribe or suppression action prematurely and may cause inconsistent behaviour in how your address is recorded in our suppression list, or interfere with suppression confirmation. Our engineering team has identified and addressed this known issue for a previous batch of affected users. - Processing queue timing — If your deletion request was submitted recently, the suppression update may still be propagating across all sending systems. Allow up to 72 hours before expecting all emails to stop. If you are still receiving emails several business days after your deletion request was acknowledged, it is likely that one of the above issues applies to your account and requires manual investigation. ✅ How to Confirm Your Account Has Been Deleted To verify the status of your GDPR deletion request: 1. Attempt to log in to Search Atlas. If your account has been successfully deleted, access will be denied and you will not be able to reach the platform dashboard. 2. Check whether you received a deletion confirmation email at the time of your request. This email serves as your primary record that the request was received and processed. 3. Check whether the emails you are receiving are transactional (such as system notifications) or marketing. Transactional emails tied to an active session should stop once the account is removed. 4. Note the date of your original deletion request and compare it to when the emails stopped or continued. If login fails and you are still receiving emails, this is a strong indicator that suppression post-processing did not complete correctly and needs to be resolved by our team. 5. If you are unsure whether your original request was received or completed, contact our support team directly using the live chat widget (see below) and provide the email address associated with your account. Our team can verify the deletion status and re-trigger email suppression if needed. ⏱️ Expected Timelines - Account deactivation — Immediate upon confirmed deletion request. - Data removal — Typically completed within a few business days. - Email suppression — Should take effect within 1–3 business days after the deletion is fully processed. - Confirmation — If you have not received confirmation and emails continue beyond 5 business days, please contact support. 🛠️ Steps to Take If You Are Still Receiving Emails If emails continue to arrive more than 72 hours after your deletion request was confirmed, follow these steps: 1. Note the subject line, sender address, and date of the email you received. 2. Check your email client's spam or promotions folder — some suppression updates take longer to reflect in filtered categories. 3. Contact our support team via the live chat widget and share the details above. Our team can manually verify your suppression record and escalate to our engineering team if a post-processing error occurred. 🔐 Your GDPR Rights at Search Atlas Under GDPR, you have the right to: - Erasure (Right to be Forgotten) — Request that all personal data we hold about you is permanently deleted. - Confirmation of deletion — Receive written confirmation that your data has been removed. - Cessation of communication — Stop receiving all marketing and transactional emails once your deletion request is processed. Search Atlas is committed to honouring these rights within the legally required timeframe. If you believe your rights have not been respected, our support team will treat your case as a priority. 💬 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. Please have the following ready to speed up your request: - The email address associated with your deleted account - The approximate date you submitted your GDPR deletion request - A sample of a recent email you received (subject line and date are sufficient)

🗺️ Disabling Heatmaps on Your PRO Plan

🔍 What Are Heatmaps in Search Atlas? Heatmaps are an optional tracking feature available on the PRO plan. When enabled, Search Atlas collects visitor interaction data — such as clicks, scrolls, and mouse movement — on your connected pages. This data is stored on Search Atlas servers and contributes to your plan usage, which may affect your billing. ⚙️ How to Disable Heatmap Tracking You can turn off heatmap tracking directly from your Search Atlas dashboard. Follow these steps: 1. Log in to your Search Atlas account. 2. Navigate to Local → Local SEO Heatmaps from the left-hand sidebar. 3. Select the website or project for which you want to disable heatmaps. 4. Click the Settings or Manage option for that project. 5. Toggle the heatmap tracking switch to Off or click Disable Heatmaps. 6. Confirm your choice when prompted. Once disabled, Search Atlas will stop collecting new heatmap data for that project immediately. 🗑️ Requesting Heatmap Data Removal Disabling heatmap tracking stops new data from being collected, but any previously recorded heatmap data may still be stored on Search Atlas servers. If you want all existing heatmap data permanently deleted from our servers, you need to submit a data removal request. To request data deletion: 1. Disable heatmap tracking for all relevant projects (see steps above). 2. Contact our support team via the live chat widget (see below) and request full removal of your stored heatmap data. 3. Our team will confirm once the data has been permanently deleted from our servers. Please note: Data removal is permanent and cannot be undone. Make sure you have exported or saved any heatmap reports you wish to keep before submitting your request. 💳 How Disabling Heatmaps Affects Your Billing The heatmap feature is included as part of the PRO plan. Here is what you need to know about billing: - Disabling heatmaps stops new data collection, but it does not automatically reduce your PRO plan subscription cost, as heatmaps are bundled within the plan tier. - If you believe you are being charged specifically for heatmap usage above your plan limits, our support team can review your account and clarify any usage-based charges. - If you no longer need the PRO plan features and wish to downgrade, contact our support team to discuss your options. ❓ Frequently Asked Questions - Will disabling heatmaps affect the rest of my PRO plan features? - No. Turning off heatmaps only stops heatmap data collection. All other PRO plan features remain fully active. - How long does it take for data to be removed after a deletion request? Our team will process your request as quickly as possible. You will receive a confirmation once deletion is complete. - Can I re-enable heatmaps after disabling them? Yes. You can re-enable heatmaps at any time from the same settings area, unless you have also requested a full data deletion. - Does disabling heatmaps remove the tracking script from my website? Disabling heatmaps within Search Atlas stops data from being recorded, but if you manually added a tracking script to your website, you may also want to remove that script from your site's code.

📘 Approval & Safety Controls

Some MCP actions require explicit user approval before they can run. This is part of the MCP safety model and is designed to prevent irreversible, destructive, or spending actions from happening silently. The Search Atlas MCP includes metadata on certain tools that marks them as approval-required. In the source, this is described as a flag marking the tool as approval-required in the MCP tool metadata. Clients that support human-in-the-loop confirmation will surface a confirmation prompt before executing those actions. Note: The MCP approval model described in this article applies specifically to MCP tool calls. Content publishing approval (for example, article publishing in Website Studio or other linked workflows) is a separate mechanism with its own controls and is covered in its own documentation. This article explains which actions require approval, how the approval flow works, what to expect in supported clients, and how this safety layer interacts with your plan permissions and billing. 🧠 Why Approval Exists The approval system exists to protect users from actions that: - spend money - delete or destroy data - trigger irreversible operations - publish or execute something with real-world consequences The source makes this especially clear for: - purchase_credits (buying additional credits, which spends money or consumes balance) - destructive OTTO operations such as otto_delete_project (deleting an OTTO project, which removes all associated configurations and cannot be undone) In practical terms, this means MCP does not simply execute every tool call the assistant proposes. For certain high-impact actions, the assistant can prepare the action — meaning it determines the correct parameters and presents them for your review, but does not submit or execute anything — and the user must still explicitly confirm before it proceeds. 🔍 What “needs approval” Means When a tool is marked with the approval flag: - the assistant can identify the action - the client can show a confirmation prompt - execution pauses until the user approves it ⚙️ Step-by-Step: How the Approval Flow Works Step 1 You ask your AI assistant to perform an action. Examples could include: - purchasing credits - deleting a project - running another action that is destructive or spend-related Step 2 The assistant interprets your request and selects the appropriate MCP tool. At this stage, the assistant is still planning the action — determining the correct parameters and preparing them for your review. It has not submitted or executed the action yet. Step 3 The MCP checks the tool’s metadata. If the tool is marked as approval-required, the execution path changes. Instead of running immediately, the client must interrupt and request confirmation from the user. Step 4 Your MCP client displays a confirmation prompt. In supported clients, this is where you are asked to explicitly approve the action before it can continue. The source names: - Claude Desktop - Claude.ai - Claude Code Step 5 You review the action and choose whether to proceed. At this point, one of two things happens: - Approve → the action executes - Do not approve → the action does not run Step 6 If approved, the MCP executes the action using your Search Atlas account, permissions, and available quota or credits. If the action involves spending or account changes, those effects occur only after approval has been granted. 📌 Actions Most Likely to Require Approval The source explicitly calls out two broad categories: 1. Spending actions These are actions where money or premium credits are being consumed. Examples from the source include: - purchase_credits (buying additional credits, which spends money or consumes balance) 2. Destructive actions These are actions that delete or irreversibly change data. Examples from the source include: - otto_delete_project (deleting an OTTO project — removes all associated configurations and cannot be undone) - other destructive OTTO operations (anything that removes, overwrites, or irreversibly changes project data) The source also makes a broader principle clear: approval is used where execution should not happen silently because the effect is meaningful, costly, or not easily undone. 🔐 Step-by-Step: What to Do When a Prompt Appears Step 1 Read the action carefully. When your client surfaces an approval request, confirm what the assistant is about to do. This is especially important if the action affects billing, deletes data, or changes a live system. Step 2 Check whether the action is expected. Ask yourself: - Is this the action I intended? - Is this a spending action? - Is this destructive or irreversible? - Am I ready for it to happen now? The source’s safety model is designed precisely so you can stop here if the action is not what you want. Step 3 Approve only if you want the action to execute. If you approve it, the MCP continues and runs the tool. If you do not approve it, execution stops. Step 4 If needed, revise your request and try again. If the assistant prepared the wrong action, do not approve it. Instead, provide a clearer instruction and let the assistant re-plan the workflow. This keeps control in your hands before any high-impact tool runs. 🧩 How Approval Interacts with Permissions Approval does not override permissions. Even if you approve an action, the action still must satisfy all normal access controls: - your plan must include the product area - your account must have the necessary entitlement - your quota or balance must be sufficient So approval is not a bypass. It is an additional safety layer on top of the normal Search Atlas access model. Example A user could approve a PPC-related action, but if their plan does not include OTTO PPC, the action still cannot execute successfully because entitlement checks happen separately. 💳 How Approval Interacts with Billing Approval is especially important for actions that involve direct spending. The source explains that money-spending actions and premium actions can involve: - Search Atlas quotas - Hyperdrive Credits - Stripe checkout for top-ups or purchases For those cases, approval ensures: - nothing is purchased silently - the user sees the action before it runs - the user remains in control of when money is spent This is why the source specifically mentions purchase_credits as an approval-required action. Note that credit-purchase approvals are still subject to your plan’s quota rules. Plan upgrades, promotional credits, or quota changes may affect which actions you can take or how much is available to spend. For full details on quotas, plan limits, and available credits, refer to the billing and quota documentation. 🛑 Cancellation, Project Deletion & Other Workflows Outside MCP Approval Some actions that users might expect approval controls to govern are actually handled outside the MCP approval flow. In particular: - Plan cancellation does not automatically delete OTTO projects or remove on-page integrations. Those artifacts persist until they are explicitly cleaned up. - Project deletion is its own workflow, separate from the MCP approval prompt. - Pending or queued destructive actions initiated through other parts of the platform are not retroactively held by the MCP approval layer. If you are cancelling a subscription, removing on-page integrations, or deleting a project, follow the dedicated offboarding and project-deletion documentation for those workflows rather than relying on the MCP approval prompt to surface them. 🧪 What Happens in Clients That Support HITL The source names three clients that support human-in-the-loop confirmation: - Claude Desktop - Claude.ai - Claude Code In these clients, when an approval-required tool is invoked, the client displays a confirmation prompt with the action details, and execution pauses until you approve or decline. Clients that do not support confirmation prompts In clients that do not implement human-in-the-loop confirmation, approval-required tools cannot be safely executed. In those environments, those tools will either return an error or be unavailable, rather than running silently. If you encounter this, use one of the supported clients listed above to complete the action. 🔄 Related Approval Flows in Search Atlas Other Search Atlas products have their own approval-style queues that are distinct from the MCP tool approval model described in this article. These are surfaced in their own product UIs, not through MCP confirmation prompts. - OTTO PPC — Pending Review queue: The auto_pause_low_quality_keywords feature surfaces auto-paused low-quality keywords in a Pending Review queue where you can approve or reject the pause. This is a separate, product-level approval flow and is not governed by the MCP needs_approval mechanism. - Content publishing approvals: Article publishing in Website Studio and linked content workflows have their own publishing controls, separate from MCP tool approvals. If you are looking for a particular approval experience and it is not appearing as an MCP confirmation prompt, check whether it lives in one of these product-level queues instead. ⚠️ Known Issues Content Genius — context loss after content plan approval: After approving a content plan in Content Genius, the agent may lose prior conversation context in some sessions. This is a known issue currently being resolved. If this occurs, re-provide your topic, keywords, and domain to continue the workflow. This callout will be removed once the fix ships.

🔑 How to Reset Your API Key After a Security Exposure

📋 Overview If your Search Atlas API key has been exposed—for example, committed to a public code repository, shared in a message, or pasted into an unsecured location—you should treat it as compromised. Anyone with your key can make requests on your behalf and consume your account resources. This article explains how to delete the exposed key, generate a new one, and update your integrations safely. ⚠️ When You Should Reset Your API Key Reset your key right away if any of the following apply: - The key was accidentally published in a public GitHub or GitLab repository. - The key was shared in an email, chat, screenshot, or support ticket. - The key appears in client-side code, logs, or a browser network tab. - You notice unexpected API activity or usage you cannot explain. - A team member with access has left your organization. 🤔 Why Resetting Matters An exposed key cannot be "un-shared." Even if you delete the post or file that contained it, automated bots routinely scan public sources for credentials. Deleting the old key is the only reliable way to stop unauthorized use. 🚫 Step 1: Revoke (Delete) the Exposed Key Deleting the key immediately blocks any further requests made with it. 1. Log in to your Search Atlas account. 2. Open Settings and select the API or API Keys section. 3. Locate the key that was exposed. If you have several keys, match it by name, creation date, or the last few visible characters. 4. Click the Delete (or Revoke) option next to that key. 5. Confirm the deletion when prompted. Once deleted, the key is permanently disabled and can no longer be used to authenticate. 🆕 Step 2: Generate a New API Key 1. In the same API Keys section, click Generate New Key (or Create API Key). 2. Give the key a clear, descriptive name so you can identify where it is used—for example, "Production Server" or "Reporting Script." 3. Copy the new key and store it immediately in a secure location, such as a password manager or your application's secrets store. ❗ Important For security, the full key is usually shown only once at creation. If you lose it, you will need to delete it and generate another. Never store API keys in plain text files, shared documents, or source code. 🔄 Step 3: Update Your Integrations After deleting the old key, any application or workflow that relied on it will stop working until you add the new key. There is no grace period—the old key is invalidated immediately. To restore service: - Replace the old key wherever it was stored—environment variables, configuration files, automation tools, or third-party connections. - Restart any services or scripts that load the key at startup. - Run a quick test request to confirm the new key authenticates successfully. 🔒 How to Keep Your API Key Secure Follow these best practices to prevent future exposures: - Use environment variables or a secrets manager. Never hard-code keys directly into your application. - Keep keys out of version control. Add configuration and secrets files to your .gitignore. - Avoid sharing keys. Do not send keys over email or chat. If a teammate needs access, have them generate their own key where possible. - Rotate keys periodically. Regularly replacing keys limits the impact of an exposure you may not be aware of. - Use separate keys per integration. This makes it easy to revoke one key without disrupting everything else. - Remove keys you no longer use. Fewer active keys means a smaller risk surface. ❓ Frequently Asked Questions Will deleting my key affect my data or account? No. Deleting an API key only disables that credential. Your account, settings, and data remain intact. Can I recover a deleted key? No. Deleted keys cannot be restored. You will need to generate a new key and update your integrations. How do I know if my key was misused? Review your API usage and activity within your account. If you see requests you did not make or unexpected spikes in usage, delete the key right away and generate a new one. How can I tell which type of API key I have? Search Atlas is migrating to API Key V2. Legacy (V1) keys are a 32-character hexadecimal string, while V2 keys begin with the sa_ prefix and are noticeably longer (around 100 characters). Use the prefix or the last few visible characters to tell your keys apart when you have more than one. What happens to my old key when I create a new one? With API Key V2 you can hold multiple named keys at once and revoke them individually. However, generating your first V2 key automatically revokes your existing legacy V1 key, so any integration still using the V1 key will stop working until you update it. V1 keys are being deprecated and will be phased out after a migration window. What if I don't see a Delete, Revoke, or Generate option in my account? Self-service key management and rotation are part of the API Key V2 rollout and may not yet be enabled on every account. If you cannot find the controls to revoke or regenerate your key, contact support and ask us to reset it for you. Please do not include the exposed key in your message—just let us know a reset is needed. 💬 Still Need Help? If you cannot locate the API Keys section, suspect ongoing unauthorized activity, or need help confirming that a key has been fully revoked, contact our support team. Please do not include the exposed key in your message—just let us know that a reset is needed.