Home 🛠️ Troubleshooting

🛠️ Troubleshooting

Camilo Aponte
By Camilo Aponte
• 49 articles

⚠️ Brand Vault Sync Error: Missing Logo, Images, and Social Profile Mappings

A Brand Vault sync error can incorrectly map asset URLs and social profile data, removing or misassigning your logo, images, and social profile URLs in the Style Guide and Knowledge Graph. Contact Search Atlas Support to request priority escalation and engineering-level data restoration. 🔍 Symptoms of the Brand Vault Sync Mapping Error A backend sync mapping error in Brand Vault incorrectly assigns asset URLs and social profile data to the wrong fields during a sync. This affects both the Style Guide and Knowledge Graph sections of your Brand Vault. You are likely affected if, after a Brand Vault sync, you see any of the following: - Your brand logo is missing from the Style Guide. - 50 or more images are missing from the Style Guide. - Social profile URLs in the Knowledge Graph are incorrectly mapped or removed entirely. 🛠️ How Search Atlas Restores Affected Accounts Accounts that report this issue through support are escalated to engineering for priority data restoration. Here is what happens after you contact support: 1. You contact support and describe the missing logos, images, or social profile URLs after the sync. 2. Your support agent escalates your account directly to the engineering team. 3. Engineering corrects the sync mapping and restores your missing assets. 4. Your logo, images, and social profile URLs are verified and confirmed restored. Support escalation is the only reliable path to restoration. Re-uploading assets or manually editing social profile fields does not fix the underlying sync mapping error. 📞 How to Request Priority Data Restoration Contact Search Atlas Support immediately if any of the following apply: - Your logo, images, or social profile URLs are missing or incorrect after a Brand Vault sync. - You need confirmation that your account has been flagged for priority restoration. - You have an urgent business need that requires immediate remediation. When you reach out, include your account name and a clear description of the affected assets. Your support agent will escalate your account to engineering and coordinate data restoration as quickly as possible. 🎯 Once you contact Search Atlas Support with your account name and a description of the missing assets, your case will be escalated to engineering for priority restoration of your logo, images, and social profile URLs.

Last updated on Oct 26, 2026

🛠️ White-Label Shared Reports Still Show the Search Atlas Logo: How to Fix It

If your shared report links still show the Search Atlas logo after your DNS is set up correctly and you've waited 72+ hours, the most common cause is opening those reports while logged into dashboard.searchatlas.com instead of your white-label domain. Log in through your white-label domain and the branding will display correctly. 🔍 Why shared reports show the Search Atlas logo instead of your branding White-label branding is tied to the domain you're logged into. When you open a shared report while signed in at dashboard.searchatlas.com, the report renders with the default Search Atlas logo, even when your DNS is configured correctly and fully propagated. This is expected behavior rather than a bug: white-label branding is scoped to your white-label domain, so shared reports only pick up your branding when they are viewed from that domain. The fix is not a DNS change or more waiting. View shared reports from your white-label domain so the platform applies your branding. ✅ How to view shared reports with your white-label branding Follow these steps to load shared reports with your own logo and branding: 1. Go to More Features → Agency Hub. 2. Log in to your account on that white-label domain. 3. Open your shared reports from that white-label domain rather than from dashboard.searchatlas.com. Once you're logged in on the white-label domain, your shared report links will display your branding instead of the Search Atlas logo. 🔑 How to log in to your white-label domain when you normally use Google login If you usually sign in with Google, you may not have a username and password set up for your white-label domain. Create one so you can log in directly on that domain. Set up a username and password 1. Open your white-label domain login page (for example, https://seo.waiev.com/login). 2. Select the Forgot password option. 3. Follow the prompts to create a username and password combination for your account. 4. Return to the login page and sign in with your new credentials. After you log in with your username and password on the white-label domain, open your shared reports there. You'll see your white-label branding applied to the report links. 🎯 You learned that white-label branding on shared reports depends on logging in through your white-label domain, not dashboard.searchatlas.com. Set up a username and password with the Forgot password option if you normally use Google login, sign in on your white-label domain, and your shared reports will display your branding.

Last updated on Oct 26, 2026

🔗 Fix White-Label Report Sharing URL Generation

🔍 Understanding the Problem If clicking Share & Export on a report produces a dashboard.searchatlas.com link instead of your branded white-label URL, you are generating the share link from the wrong environment. Report sharing must be performed from inside your white-label dashboard, not from your Search Atlas account dashboard. This is the most common cause of this issue and does not indicate a configuration error with your white-label setup. 🌐 Step 1: Access Your White-Label Environment Your white-label environment has its own dedicated URL, separate from dashboard.searchatlas.com. To navigate to it: 1. Open a new browser tab. 2. Go to the custom domain you configured for your white-label dashboard (for example, reports.youragency.com or the subdomain you set during white-label setup). 3. Log in using your agency admin credentials. If you are unsure what your white-label URL is, check the domain you entered during white-label configuration inside Search Atlas. You can find this by going to More Features → Agency Hub (Agency Hub / White Label settings) and reviewing your white-label domain settings. 📊 Step 2: Open the Report Inside the White-Label Dashboard Once you are logged in to your white-label environment, navigate to the report you want to share: 1. In the left sidebar, click Reports → Report Builder. 2. Locate the report project you want to share from the projects list. 3. Click View to open the report (Executive Summary). It is important to complete this step from within the white-label dashboard. If you open the report from dashboard.searchatlas.com, the generated share link will reflect that domain instead of your branded URL. 🔗 Step 3: Generate the White-Label Share URL With the report open inside your white-label environment: 1. Click the Share & Export button within the report. 2. The generated link should now display your white-label domain (for example, reports.youragency.com/...). 3. Copy the link and share it directly with your client. Your client will see the report under your branded domain with no Search Atlas branding visible. ✅ Quick Checklist Before Sharing - The browser address bar shows your white-label domain, not dashboard.searchatlas.com. - You are logged in as the agency admin inside the white-label environment. - The generated Share URL begins with your custom branded domain. - The report content and data are loading correctly before you copy the link. ⚠️ Common Mistakes to Avoid - Do not copy a dashboard.searchatlas.com link and manually replace the domain. This will produce a broken or inaccessible URL for your clients. - Do not attempt to generate the share link from the Search Atlas main dashboard even if the report data looks identical. The environment you are in at the time of generation determines the URL that is produced. - If you have multiple white-label domains configured, make sure you are logged in to the correct one for the client you are sharing with. 🛠️ If Your White-Label URL Is Not Working If you cannot access your white-label environment or the domain is not loading, check the following before re-attempting report sharing: - Confirm your white-label domain is correctly configured and DNS records are fully propagated. - Verify your white-label setup is active and not paused inside your Search Atlas account settings. - Try accessing the white-label URL from a different browser or an incognito window to rule out caching issues. If the white-label domain loads but Share & Export still generates a searchatlas.com link, log out and log back in to the white-label environment, then try again. 💬 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.

Last updated on Oct 26, 2026

Access Your White-Label Domain and Client Reports

Overview When you set up a white-label domain in Search Atlas, visiting the root URL (for example, app.youragency.com) lands you on the /register page by default. This page displays an "invitation required" message because self-registration is intentionally disabled for white-label portals. This is expected behavior — it is not an account error or an access problem. To log in, you and your clients must always navigate to the explicit /login path. This article explains how to reach the login page and how to share the correct entry point with clients. Why the Root URL Shows "Invitation Required" White-label portals are closed environments. The default landing page (/register) blocks open sign-ups to protect your client workspace. Because there is no way to bypass this message from the register page, going directly to the root domain will always produce this result. This is by design and does not indicate any problem with your account or domain configuration. How to Log In to Your White-Label Domain 1. Open your browser and go to your white-label domain followed by /login. For example: app.youragency.com/login 2. Enter your Search Atlas credentials (email and password). 3. Submit the login form. You will be taken directly into your white-label portal. Tip: Bookmark yourdomain.com/login and share this exact URL with every client. Never share the root domain URL on its own. How to Get a Client's Report URL for Iframing Once you are logged in to your white-label portal, navigate to the specific client report you want to share or embed. 1. Open the client project whose report you want to share. 2. Navigate to the specific report you want to embed. 3. Copy the full URL from your browser's address bar. This is the URL you will use as the src value in your iframe code. 4. Ensure the client accessing the iframe is already authenticated at yourdomain.com/login before loading the embedded report. Unauthenticated users will be redirected to the login page. Sharing Access With Clients When inviting clients to view their reports through your white-label portal, always send them: - The direct login URL: yourdomain.com/login - Their individual login credentials so they can authenticate before accessing any report links If you need further assistance setting up your white-label domain or retrieving report URLs, please reach out to our support team via the chat widget in your Search Atlas dashboard.

Last updated on Oct 26, 2026

🌐 Fix White-Label Domain DNS Configuration Issues

🔍 Overview White-labeling allows you to serve the Search Atlas dashboard under your own custom domain (for example, dashboard.youragency.com). If your white-label URL is returning an error page instead of loading the dashboard, the most common cause is an incomplete or incorrect DNS configuration. This article walks you through the correct setup and how to troubleshoot the most frequent issues. ⚙️ Prerequisites - Access to your domain registrar or DNS provider (e.g., Cloudflare, GoDaddy, Namecheap). - Admin access to your Search Atlas account with Agency settings enabled. - The subdomain you want to use (e.g., dashboard.youragency.com). 🛠️ How to Configure Your White-Label Domain 1. Log in to Search Atlas and go to the apps-grid icon in the header → More Features → Agency Hub (Agency Settings). 2. Locate the White-Label Domain field and enter your chosen subdomain (e.g., dashboard.dotmappers.in). 3. Save your settings. Search Atlas will display the DNS record values you need to add at your domain registrar. 4. Log in to your DNS provider and create a new CNAME record with the following details: - Host / Name: The subdomain prefix only (e.g., dashboard). - Points to / Value: The CNAME target provided by Search Atlas (copy it exactly). - TTL: 3600 (1 hour) or your provider's default. 5. Save the DNS record at your provider. 6. Wait for DNS propagation — this typically takes 15 minutes to 48 hours depending on your provider and TTL settings. ✅ How to Verify Your DNS Is Propagating Before assuming something is broken, confirm that your DNS record has propagated correctly: - Visit dnschecker.org or whatsmydns.net and enter your full subdomain (e.g., dashboard.dotmappers.in). Select CNAME as the record type. You should see the Search Atlas CNAME target resolving across multiple locations. - If the record is not yet visible, wait and check again in 30–60 minutes. - If the record shows a different value, update it in your DNS provider to match the value provided in Search Atlas Agency Settings exactly. 🚨 Common Errors and Fixes - Error page / domain not loading: DNS has not yet propagated or the CNAME record is missing. Double-check that you created a CNAME (not an A record) and that the target value matches exactly what Search Atlas provided. - SSL / HTTPS warning: SSL certificates are provisioned automatically by Search Atlas after the CNAME propagates. If you see an SSL error shortly after setup, wait up to 30 minutes for the certificate to be issued. Do not add your own SSL certificate. - Subdomain resolves but shows a blank or broken page: Confirm the full subdomain entered in Agency Settings matches the subdomain you created in your DNS (including any hyphens, dots, or capitalisation). - Cloudflare users — proxy status: If your domain is managed by Cloudflare, make sure the CNAME record is set to DNS only (grey cloud icon), not Proxied (orange cloud). Proxying can interfere with SSL provisioning. - Previous A record conflict: If an A record already exists for the same subdomain, delete it before adding the CNAME record. Two conflicting records will prevent the domain from resolving correctly. 📋 DNS Configuration Checklist - Record type is CNAME (not A, AAAA, or TXT). - Host/Name value is the subdomain prefix only (e.g., dashboard, not the full domain). - CNAME target matches the value shown in Search Atlas Agency Settings exactly. - No conflicting A record exists for the same subdomain. - Cloudflare proxy is disabled (grey cloud) if applicable. - Sufficient time has passed for DNS propagation (up to 48 hours). - The full subdomain saved in Agency Settings matches what you configured in DNS. 💡 Tips for Faster Troubleshooting If you need to speed up testing during setup, temporarily lower your TTL to 300 seconds (5 minutes) before making DNS changes. This reduces the time it takes for updates to propagate. Once everything is working, you can raise the TTL back to 3600. Also, try accessing your white-label URL in an incognito or private browser window to rule out cached DNS responses on your local machine. 🙋 Still Need Help? If you have followed all the steps above and your white-label domain is still not loading 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.

Last updated on Oct 26, 2026

⚠️ WhiteLabel Website Builder: CDN Image URLs Show searchatlas.com Domain

CDN image URLs generated by the WhiteLabel Website Builder currently display searchatlas.com instead of your white-labeled domain. This is a confirmed platform limitation with no workaround — the Search Atlas development team is actively building a fix. 🔍 What Is Happening When the WhiteLabel Website Builder embeds images on your site (for example, yourclientdomain.com), the CDN (Content Delivery Network) URLs that serve those images reference searchatlas.com rather than your custom domain. These URLs are visible in page source code, which can expose the Search Atlas platform domain to your end clients and search engines, undermining your white-label branding and SEO signals. ⚠️ Current Status: Known Limitation Custom CDN domain mapping for the WhiteLabel Website Builder is not yet supported. This is not a misconfiguration on your account — it is a confirmed gap in the current feature set, acknowledged by the Search Atlas development team. There is no manual workaround available at this time. 🔗 Related Known Issue: Google Indexing the Origin Domain Some customers also notice their WhiteLabel site appearing in Google search results under the searchatlas.com origin domain instead of their custom domain. This is a separate but related manifestation of the same white-label domain gap and is also under active remediation by the Search Atlas development team. If you are seeing both symptoms, you do not need to open separate support tickets — they are tracked as companion issues. 🚀 Fix In Progress The Search Atlas development team is actively building support for custom CDN domains within the WhiteLabel Website Builder. Watch for a release announcement in-app or via email — no action is required from you before the release. 📋 What to Do Now - Do not attempt to reconfigure CDN settings. The CDN domain is assigned automatically by the platform and cannot be changed through any current setting or toggle. - Watch for a release announcement via email or in-app notifications when the update goes live. - Contact Search Atlas Support if you need an updated timeline or want to confirm whether the upcoming release also resolves the Google indexing variant for your account. 🌀 Once the custom CDN domain feature ships, image URLs on your WhiteLabel site will automatically reflect your own domain. Contact Search Atlas Support if you need a progress update before the release.

Last updated on Oct 26, 2026

🛠️ White Label DNS Configuration Troubleshooting Guide

🔍 Overview Setting up DNS for your White Label can feel complex, and propagation delays or small configuration mistakes can make it hard to tell whether the setup worked. This guide walks you through the correct configuration steps, common mistakes to avoid, and how to verify your setup is working. ⚙️ Required DNS Records To connect your custom domain to Search Atlas White Label, you must add the following records in your domain registrar or DNS provider's control panel: - Type: CNAME - Host / Name: The subdomain you want to use (e.g., reports or app) - Value / Points to: The target hostname provided in your Search Atlas White Label settings - TTL: 3600 (1 hour) or the lowest value your provider allows Do not add an A record or MX record in place of the CNAME — these will not work for White Label setup. 🚨 Common Configuration Mistakes The following errors are the most frequent causes of a failed DNS setup: - Using the root domain instead of a subdomain: Most DNS providers do not allow a CNAME on a root domain (e.g., yourdomain.com). Always use a subdomain such as reports.yourdomain.com. - Trailing dot or extra characters: Copy the target value from Search Atlas exactly. Even a single extra character or space will break the record. - Conflicting records: If a previous A record or CNAME already exists for the same subdomain, delete it before adding the new CNAME. - Proxy enabled in Cloudflare: If you use Cloudflare, ensure the proxy toggle (orange cloud) is set to DNS only (grey cloud) for the CNAME record. - Incorrect subdomain in Search Atlas settings: The subdomain you enter inside Search Atlas must exactly match what you configured at your DNS provider. ⏱️ Understanding DNS Propagation After saving a DNS record, changes do not take effect immediately. Propagation can take anywhere from 15 minutes to 48 hours depending on your DNS provider and the previous TTL value. During this window, the domain may appear broken even when the configuration is correct. To check propagation status, use a free tool such as whatsmydns.net and search for your subdomain as a CNAME record. Once you see your target hostname returned consistently across multiple global locations, propagation is complete. ✅ Step-by-Step Verification Checklist Work through the following steps in order before concluding there is a technical issue: 1. Log in to your DNS provider and confirm the CNAME record is saved with the exact target value from Search Atlas. 2. Check that no conflicting A record or old CNAME exists for the same subdomain and delete any conflicts. 3. If using Cloudflare, confirm the proxy is set to DNS only. 4. Wait at least 1 hour after saving and then check propagation on whatsmydns.net. 5. Log in to Search Atlas and re-open your White Label settings to confirm the custom domain field is saved correctly and matches your subdomain exactly. 6. Open the subdomain URL in an incognito or private browser window to avoid cached results. 🔄 When to Re-Save Your White Label Settings If you recently corrected a DNS record, you may also need to re-save your White Label configuration inside Search Atlas to trigger a fresh connection check. Navigate to your White Label settings, confirm all fields are correct, and click Save again. Then allow up to 30 minutes for the platform to re-validate the domain. 💡 Still Not Working After 48 Hours? If more than 48 hours have passed, your DNS records appear correct on whatsmydns.net, and your White Label domain is still not loading, there may be an issue on the platform side that requires investigation. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. Please have the following ready to share: your custom subdomain, a screenshot of your DNS record, and your whatsmydns.net results — this will help our team resolve your issue as quickly as possible.

Last updated on Oct 26, 2026

🔒 Fixing White Label Report 'Invitation Required' Access

🔍 What This Article Covers If you clicked View Report in an email and were met with an Invitation Required message instead of your report, this article explains why it happens and how to gain access quickly. ❓ Why You See 'Invitation Required' White label reports are shared through a secure, invitation-based system. The Invitation Required message appears when the platform cannot confirm that the person opening the link has been granted access. This is a security feature that protects your data and keeps reports private. The most common reasons are: You are signed in with an email address that does not match the one the report was shared with. - You opened the link while logged into a different account. - The invitation has not yet been accepted for the account you are using. - You were invited but have not finished setting up your account — for example, a password was never set for the invited email. - The report link was forwarded to you by someone other than the original recipient. ✅ How to Open Your Report Follow these steps in order to resolve the issue: 1. Confirm you are opening the report using the same email address the invitation was sent to. 2. Sign out of any other accounts you may be logged into in your browser. 3. Return to the original email and click View Report again. 4. When prompted, use the invitation to sign in or finish setting up your account — including setting a password if you have not done so already — with the exact email address that received the invitation. On white label domains, self-registration is disabled, so invited users are guided to the dashboard rather than a separate sign-up page. 5. Once signed in with the matching email, the report will open automatically. 🧭 If You Still Cannot Access the Report If the message continues to appear, try these additional checks: - Check the email address: Make sure there are no typos and that you are not using an alias or forwarding address. - Use the original email: Open the link directly from the invitation email rather than a forwarded copy. - Clear your browser cache: Old sign-in data can interfere with access. Clearing your cache or using a private browsing window often helps. - Check the report URL: If the report link opens dashboard.searchatlas.com instead of your agency's white label domain, this is a known issue our engineering team is currently working on. Please contact support so the report can be re-shared from the correct domain. - Ask the sender to re-share: Request that the report owner send a fresh invitation to your correct email address. 👥 For Report Owners Sharing a Report If you are the person sharing a white label report and your recipient reports this issue, confirm the following: - You entered the recipient's correct email address when sharing. - The recipient is opening the link with that same address. - The recipient has completed account setup (including setting a password) from the invitation, since invited users cannot self-register on a white label domain. - You re-send the invitation if the email address was incorrect or has changed. Sending a new invitation to the verified email address resolves most access problems immediately.

Last updated on Oct 26, 2026

🎨 Fix White Label Branding Colors in Reports

🔍 Overview If you have configured custom branding colors in your White Label settings but those colors are not appearing in your reports, you are not alone. This is a known issue currently being addressed by our engineering team. This article explains what is happening, which areas are affected, and what you can do in the meantime. ⚠️ Known Issue: Brand Colors Not Applying to Reports Our team has identified that custom White Label brand colors are not consistently applying across all areas of the platform. The following areas are affected: - Report Builder (PDF and HTML exports): Custom dashboard colors defined in your White Label settings are not yet inherited by generated reports. A fix is currently in development. - White Label Dashboard and Pricing Page: Brand colors may not fully apply to the White Label client-facing dashboard and pricing page. This is actively being developed. - Authority Section: Custom color support for the Authority dashboard is open and scheduled for a future release. - Home Page: White Label brand color support for the Home page is also open and planned for an upcoming update. The fix for Report Builder color support has already been completed in our system and is part of a broader rollout. Full color inheritance across all White Label areas — including PDF and HTML report generation — is currently in active development. ✅ What Is Currently Working Your White Label branding colors that you have saved in your White Label settings are stored correctly. The issue is with how those colors are rendered in certain areas of the platform, not with how they are saved. Your configuration does not need to be re-entered once the fix is fully deployed. 🛠️ Steps to Take Right Now 1. Verify your brand colors are saved correctly. Navigate to your White Label settings and confirm your primary, secondary, and accent colors are entered and saved as intended. This ensures your colors will apply automatically once the fix is deployed. 2. Check your reports in the Report Builder. Go to Left sidebar → Reports (or navigate to /report-builder/projects-list) and open an existing report or generate a new one to see the current state of color rendering in your account. 3. Re-generate any existing reports. In some cases, regenerating a report after re-saving your White Label settings can prompt the latest available color styles to apply. This may partially improve results depending on your account configuration. 4. Note the affected sections. If you are preparing reports or dashboards for clients, be aware that the White Label dashboard, pricing page, Authority section, and Home page may also display default colors rather than your custom brand colors until the full fix is deployed. 💡 Tips While You Wait for the Full Fix - If you are sharing reports with clients before the fix is live, consider adding a brief note to clients that custom branding is being finalized, so they are aware of the temporary appearance. - Avoid making repeated changes to your White Label color settings as a troubleshooting step — your saved configuration is correct and will be used once the platform rendering is updated. - Keep an eye on platform release notes and announcements for updates on when full White Label color support will be available across all sections. 📋 Summary of Affected Areas and Status - Report Builder (PDF/HTML): Fix in active development — coming soon. - White Label Dashboard and Pricing Page: Fix in active development. - Authority Section: Scheduled for a future release. - Home Page: Scheduled for a future release. 💬 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.

Last updated on Oct 26, 2026

🛠️ Fix White Label Dashboard Connection Issues

🔍 Overview If your white label dashboard isn't connecting correctly, this guide walks you through the most common causes and fixes. Follow each step in order before reaching out for additional support. ✅ Step 1: Verify Your DNS Settings Incorrect DNS configuration is the most frequent cause of white label connection failures. Check the following: - CNAME record: Confirm your CNAME record points exactly to the domain provided in your Search Atlas white label setup. Even a single character mismatch will break the connection. - TTL propagation: DNS changes can take up to 48 hours to fully propagate. If you made changes recently, allow time before concluding there is a problem. - No conflicting records: Make sure no other A or CNAME records exist for the same subdomain. Conflicts prevent correct resolution. ⚙️ Step 2: Check Your White Label Configuration in Search Atlas Log in to Search Atlas and review your white label settings: 1. Navigate to More Features → Agency Hub (Agency Settings, URL: /agency-settings). 2. Locate the White Label section and confirm the custom domain entered matches your DNS record exactly — including whether or not you included www. 3. Ensure your logo, brand colors, and agency details are saved. Incomplete profiles can occasionally prevent the dashboard from loading for clients. 4. Save any changes and allow a few minutes for the platform to apply them. 🌐 Step 3: Test the Connection After verifying your settings, test the connection with these methods: - Incognito/private browser window: Open your white label URL in a private window to avoid cached data interfering with the result. - Different browser or device: Rule out browser-specific issues by testing on Chrome, Firefox, or Safari. - DNS lookup tool: Use a free tool such as MXToolbox or WhatsMyDNS to confirm your CNAME record is resolving correctly worldwide. - Clear your cache: If you see an outdated version of the dashboard, clear your browser cache and cookies, then reload. 🔒 Step 4: Check SSL Certificate Status A missing or invalid SSL certificate will cause browsers to block access to your white label dashboard entirely. - Search Atlas automatically provisions an SSL certificate once your CNAME record is correctly pointed and propagated. - If your browser shows a security warning, DNS propagation may still be in progress. Wait 24–48 hours after your DNS change before re-testing. - If the certificate error persists beyond 48 hours, there may be a provisioning issue that requires manual intervention from our team. 📊 Step 5: Confirm Report Access Is Working Once the dashboard connection is established, verify your client reports are accessible: 1. Go to Reports via the left sidebar (URL: /report-builder/projects-list). 2. Open a report that is shared with your client and copy the share link. 3. Paste the link into an incognito window to simulate the client experience and confirm it loads under your white label domain. 🚫 Common Mistakes to Avoid - Using the root domain instead of a subdomain: White label requires a subdomain (e.g., reports.youragency.com), not the root domain. - Copying the CNAME value with extra spaces: Always paste the CNAME value carefully. Hidden spaces cause resolution failures. - Testing too soon after DNS changes: Partial propagation can produce inconsistent results. Test from multiple locations or use a propagation checker. 💡 Preparing for a Client Meeting If you have an upcoming client meeting and the dashboard is not yet resolving, consider these temporary options: - Share reports directly from Search Atlas using the standard share link while your white label domain propagates. - Export report data as a PDF from the Reports section (left sidebar → /report-builder/projects-list) to present offline. - Contact our support team immediately (see below) so we can prioritise your case. 🙋 Still Not Working? If you have followed all the steps above and your white label dashboard is still not connecting, our team can investigate your specific domain and account configuration 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.

Last updated on Oct 26, 2026

🔒 Fix 'Invitation Required' on White Label Reports

🧭 Overview When you share a white-label report by email and the recipient clicks View Report, they may see an Invitation Required message instead of the report. This is not a broken link or a browser issue — it is an access control feature built into Search Atlas white-label reports. Only specific account types are authorized to open these links. 🔍 Why This Message Appears White-label reports in Search Atlas are protected by account-based access. The Invitation Required message appears when the person opening the link is not logged into an authorized account. The two account types that can open a shared white-label report are: - Admin account — the Search Atlas account that created the report. - Invited customer account — a client account that has been explicitly invited to view the report from within the platform. Anyone else who clicks the link — including people who are not logged in, or users logged into a different Search Atlas account — will see the Invitation Required message. Clearing cookies, using incognito mode, or regenerating the link will not resolve this issue. ✅ How to Fix the Issue Choose the option below that matches your situation. Option 1: The viewer is your client and does not yet have an invited account 1. Log in to Search Atlas with your admin account. 2. In the left sidebar, click Reports (URL: /report-builder/projects-list). 3. Open the report you shared. 4. Locate the sharing or access settings for that report. 5. Enter your client's email address to send them an official invitation. 6. Ask your client to accept the invitation and log in before clicking the report link again. Option 2: You (the admin) want to view the report yourself 1. Make sure you are logged in to the Search Atlas admin account that created the report. 2. Click the View Report link again. 3. The report should now load correctly. Option 3: Your client has already been invited but still sees the error 1. Ask your client to go to app.searchatlas.com and log in to their invited account first. 2. Once logged in, they should click the View Report link from the email. 3. If they have forgotten their password, they can use the Forgot Password option on the login page. ⚠️ Common Mistakes to Avoid - Do not forward the report link to someone who has not been invited — they will always see the Invitation Required message regardless of their browser or device. - Do not assume the link is broken just because it shows this message. The link itself is valid; the issue is account authorization. - Do not ask the recipient to try incognito mode — this logs them out and makes access impossible. 📋 Quick Reference: Who Can Open a White-Label Report? - ✅ Admin account (creator of the report) — logged in - ✅ Invited customer account — logged in and invitation accepted - ❌ Anyone not logged in - ❌ Users logged into a different Search Atlas account - ❌ Anyone who has not received and accepted an invitation 💬 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.

Last updated on Oct 26, 2026

🔌 White Label Dashboard Connection Troubleshooting Guide

🧭 Overview If your white label dashboard is not connecting correctly, this guide walks you through the most common causes and how to resolve them — so you can get your client dashboard live as quickly as possible. ✅ Prerequisites Before You Begin Before troubleshooting the connection, confirm the following requirements are in place: - Active white label plan: White label dashboards are available on qualifying Search Atlas subscription tiers. Confirm your plan includes this feature. - Custom domain purchased and active: You must own the domain you intend to use and it must be active with your domain registrar. - Access to your DNS settings: You will need to update DNS records through your domain registrar (such as GoDaddy, Namecheap, or Cloudflare). - SSL provisioned: Search Atlas provisions SSL automatically once DNS is correctly configured. Do not add a conflicting SSL certificate manually. 🔍 Step 1 — Verify Your DNS Records Incorrect DNS configuration is the most common cause of white label dashboard connection failures. Follow these steps: 1. Log in to your domain registrar's control panel. 2. Navigate to the DNS settings for your white label domain. 3. Confirm that a CNAME record points your subdomain (for example, dashboard.yourcompany.com) to the Search Atlas target hostname provided in your white label setup screen. 4. Remove any conflicting A records or duplicate CNAME entries for the same subdomain. 5. Save your changes. Important: DNS propagation can take up to 48 hours, but typically completes within 1–4 hours. Use a free tool such as dnschecker.org to confirm propagation status across global servers before assuming the connection has failed. ⚙️ Step 2 — Check Your White Label Settings in Search Atlas 1. Log in to Search Atlas and click the apps-grid icon in the header. 2. Go to More Features → Agency Hub → White Label Setup (Logo page). 3. Confirm the following fields are filled in correctly: your custom domain, your agency logo, and your brand color selections. 4. Verify that the custom domain entered in Search Atlas exactly matches the subdomain you configured in your DNS records — including correct spelling and no trailing slash. 5. Click Continue if you make any changes. 🚨 Step 3 — Identify Your Error Type Match your current issue to one of the common failure modes below: - Browser shows "This site can't be reached" or DNS error: DNS records have not propagated yet, or the CNAME record is missing or incorrect. Revisit Step 1. - Browser shows a security warning or SSL error: SSL has not yet been provisioned. This resolves automatically within a few hours of correct DNS propagation. Do not install a manual certificate. - Page loads but shows a Search Atlas branded page instead of your white label: The custom domain in your White Label settings does not match your DNS record. Revisit Step 2 and ensure exact spelling on both sides. - Page loads but branding is missing or incorrect: Return to your White Label settings, re-upload your logo, and confirm your color and font selections are saved. - Login or access errors for your client: Confirm your client has been invited and has an active account. Check user permissions in your agency settings. 🔄 Step 4 — Clear Cache and Test in Incognito After making any changes, always test your white label dashboard URL in a private or incognito browser window. Cached data can cause a correctly configured dashboard to appear broken. Ask your client to do the same before your meeting. 📋 Step 5 — Confirm With a Checklist Run through this final checklist before concluding your troubleshooting: - CNAME record is correctly added in your registrar's DNS panel - No conflicting A records or duplicate CNAMEs exist for the subdomain - DNS propagation confirmed via a checker tool - Custom domain in Search Atlas white label settings matches DNS exactly - SSL is active (no browser security warning) - Logo, colors, and branding saved in white label settings - Tested in an incognito browser window ⏫ When to Escalate to Our Team Escalate immediately if any of the following apply: - DNS has fully propagated (confirmed by a checker tool) but the dashboard still does not load after 4+ hours - You see a 500 server error or unexpected Search Atlas error page on your custom domain - SSL was not automatically provisioned within 6 hours of confirmed DNS propagation - You have completed all steps above and the issue persists If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🌐 Fix White-Label Domain DNS for GoHighLevel

🔍 Why Your White-Label Domain Is Not Working If you visit your white-label agency domain and see a message like "Looks like the page you're trying to access does not exist", the most common cause is an incomplete or incorrect DNS configuration. Your custom domain needs to point to Search Atlas servers before the white-label preview can load correctly. This guide walks you through every step to get your domain live. 📋 What You Need Before You Start - Admin access to your domain registrar (e.g., GoDaddy, Namecheap, Cloudflare) - Your white-label subdomain chosen and entered inside Search Atlas (e.g., reports.youragency.com) - Admin access to your GoHighLevel account if you are routing through a GoHighLevel sub-account - A few minutes of patience — DNS changes can take up to 48 hours to fully propagate ⚙️ Step 1: Confirm Your White-Label Domain in Search Atlas 1. Log in to Search Atlas and navigate to your Agency Settings or White-Label configuration panel. 2. Confirm the exact subdomain you have entered (e.g., reports.youragency.com). Copy it exactly — spelling and punctuation matter. 3. Note the CNAME target value displayed on that page. You will need this in the next step. It typically looks like whitelabel.dns.searchatlas.com or similar. 🛠️ Step 2: Add the CNAME Record at Your Domain Registrar 1. Log in to the control panel of the registrar where your domain is registered. 2. Go to DNS Management or DNS Records for your domain. 3. Create a new CNAME record with these values: - Host / Name: the subdomain prefix only (e.g., reports if your full subdomain is reports.youragency.com) - Value / Points to: the CNAME target value copied from Search Atlas in Step 1 - TTL: 3600 (1 hour) or the lowest value your registrar allows 4. Save the record. Important: If you already have an A record or conflicting CNAME for the same subdomain, delete it before adding the new CNAME record. Conflicting records will prevent the domain from resolving correctly. 🔗 Step 3: Configure the Domain Inside GoHighLevel If you are using GoHighLevel to host client portals or route traffic through a sub-account, you must also register the custom domain inside GoHighLevel so the two platforms can communicate correctly. 1. Log in to GoHighLevel and open the relevant Sub-Account. 2. Go to Settings → Domains. 3. Click Add Domain and enter the same subdomain you configured in Search Atlas (e.g., reports.youragency.com). 4. GoHighLevel will verify the domain by checking the CNAME record you added in Step 2. Verification may take a few minutes. 5. Once verified, set this domain as the primary domain for the sub-account if you want all white-label report links to use it. Note: If GoHighLevel shows a verification error immediately after you add the CNAME record, wait 15–30 minutes and try verifying again. DNS changes are not always instant. ✅ Step 4: Test and Verify Your White-Label Domain 1. Open a private or incognito browser window to avoid cached results. 2. Type your full white-label subdomain into the address bar and press Enter. 3. You should see your branded Search Atlas report portal instead of the error page. 4. If the error persists, use a free DNS checker tool (such as dnschecker.org) to confirm your CNAME record has propagated globally. Enter your subdomain, select CNAME as the record type, and check that results point to the correct Search Atlas target. ⏱️ DNS Propagation: What to Expect DNS changes do not apply instantly. Propagation typically takes 15 minutes to 4 hours for most regions, but can take up to 48 hours in rare cases depending on your registrar and TTL settings. During this window, some locations may still see the error page while others load correctly — this is normal. Avoid making further DNS changes during this period as it can restart the propagation timer. 🚨 Common Mistakes to Avoid - Using the full domain as the Host value — enter only the subdomain prefix (e.g., reports, not reports.youragency.com) unless your registrar specifically requires the full domain. - Skipping the GoHighLevel domain step — configuring DNS alone is not enough if you use GoHighLevel; both platforms must recognise the domain. - Cloudflare proxy enabled — if your domain is managed through Cloudflare, make sure the CNAME record is set to DNS only (grey cloud icon), not proxied (orange cloud). The Search Atlas white-label integration requires direct DNS resolution. - Testing too soon — always test in a private window after waiting at least 15 minutes. 💬 Still Seeing the Error? If you have followed all the steps above and your white-label domain is still not loading 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.

Last updated on Oct 26, 2026

🌐 Fix Whitelabel DNS Errors on Webflow

🔍 Overview When setting up your Search Atlas whitelabel on a Webflow site, you may encounter errors such as "whitelabel error" or "domain is unreachable". These messages almost always point to a DNS misconfiguration. This guide walks you through the exact steps to configure your DNS records correctly in Webflow and get your whitelabel up and running. ⚠️ Common Causes of These Errors - The required CNAME record has not been added to your Webflow domain settings. - The CNAME record was added incorrectly (wrong host name or target value). - DNS changes have not yet propagated (this can take up to 48 hours). - The custom domain has not been verified or published inside Webflow. 🛠️ Step-by-Step: Configure DNS in Webflow 1. Log in to Search Atlas and navigate to More Features → Agency Hub (Agency Hub / White Label settings). Copy the CNAME target value provided — you will need this in the next steps. 2. Log in to your Webflow account and open the project you want to connect. 3. Click the Site Settings icon (gear icon) for your project, then go to the Publishing tab. 4. Under Custom Domains, ensure your custom domain is already added. If not, enter your domain and click Add. 5. Webflow will display the DNS records you need to set up. You will need to add a CNAME record through your domain registrar (for example, GoDaddy, Namecheap, Cloudflare, or Google Domains) — Webflow does not manage DNS records directly unless you use Webflow's own hosting with a connected registrar. 6. Go to your domain registrar's DNS management panel and add a new record with the following details: - Type: CNAME - Host / Name: The subdomain you are whitelabeling (for example, app or dashboard) - Target / Value: The CNAME target copied from your Search Atlas whitelabel settings - TTL: 3600 (or the default value your registrar recommends) 7. Save the record in your registrar's DNS panel. 8. Return to Webflow Site Settings → Publishing and click Publish to apply the latest settings. 9. Back in Search Atlas, go to More Features → Agency Hub (Agency Hub / White Label settings) and click Verify Domain (or the equivalent button shown). If DNS has propagated, the domain status will update to active. ⏱️ Waiting for DNS Propagation After adding or updating a DNS record, changes can take anywhere from a few minutes to 48 hours to propagate globally. During this window, you may still see the "domain is unreachable" error — this is normal. To check propagation status, use a free tool such as whatsmydns.net and search for your subdomain to see whether the CNAME record is resolving correctly worldwide. ✅ How to Confirm Everything Is Working - Your CNAME record appears correctly in your registrar's DNS panel. - A propagation checker confirms the subdomain resolves to the correct target. - The domain status in Search Atlas Whitelabel settings shows as Active or Verified. - Visiting your whitelabel URL in a browser loads the platform without any error messages. 🔧 Troubleshooting Tips - Double-check for typos in both the host name and the CNAME target value — even a single extra character will cause an error. - Remove any conflicting A records that point to the same subdomain, as these can override your CNAME. - If you use Cloudflare as your DNS provider, make sure the CNAME record is set to DNS only (grey cloud), not proxied (orange cloud), during initial setup. - Clear your browser cache or test in an incognito window to rule out locally cached errors. - If you recently changed your DNS records, allow the full 48-hour propagation window before concluding there is an issue. 💬 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.

Last updated on Oct 26, 2026

🌐 Fix White Label DNS Configuration Issues Fast

🔍 Overview If your White Label domain is not resolving correctly after DNS setup, the most common cause is using the wrong DNS record type. This guide walks you through the correct configuration, how to spot mistakes, and how to verify that your DNS changes have taken effect. ⚠️ The Most Common Mistake: A Record vs. CNAME Record Search Atlas White Label requires a CNAME record, not an A record. This is the single most frequent cause of DNS failures. - A record — maps a domain to a specific IP address. Search Atlas does not use a static IP for White Label, so A records will not work reliably and will cause the domain to fail or resolve incorrectly. - CNAME record — maps your custom domain to another domain name (a hostname). This is the correct record type for Search Atlas White Label because it points to our infrastructure hostname, which handles routing automatically. If you have an A record in place, delete it before adding the CNAME. Having both at the same time will cause conflicts and prevent the domain from resolving. ✅ Correct CNAME Configuration Use the following structure when adding your CNAME record in your DNS provider (such as Cloudflare, GoDaddy, Namecheap, or Route 53): - Type: CNAME - Name / Host: The subdomain you want to use for your White Label (for example, reports if your White Label URL will be reports.yourdomain.com) - Value / Target / Points to: The hostname provided inside your Search Atlas White Label settings (for example, whitelabel.dns.searchatlas.com) - TTL: 3600 (1 hour) or Auto if your provider offers it Example: If your agency domain is agencypro.com and you want your clients to access reports at reports.agencypro.com, your CNAME record should look like this: - Type: CNAME - Name: reports - Value: whitelabel.dns.searchatlas.com Always copy the exact hostname from your Search Atlas dashboard. Do not guess or modify it. A single typo will cause the configuration to fail. 🔎 How to Verify Your DNS Is Configured Correctly After saving your CNAME record, follow these steps to confirm the setup before assuming something is broken. 1. Wait for propagation. DNS changes can take anywhere from a few minutes to 48 hours to propagate globally. Most changes resolve within 1–4 hours. Do not make additional edits during this window, as each change resets propagation time. 2. Check using a DNS lookup tool. Visit a free tool such as dnschecker.org or whatsmydns.net. Enter your White Label subdomain and select CNAME as the record type. You should see your Search Atlas hostname appear as the target across most global locations. 3. Clear your browser cache. If the lookup tool shows the correct CNAME but your browser still does not load the page, clear your cache or test in an incognito window. 4. Check for conflicting records. Log in to your DNS provider and search for any A records, AAAA records, or duplicate CNAME entries under the same subdomain name. Remove any conflicting records. 🧭 Diagnosing Persistent DNS Failures If you have followed all the steps above and the domain still does not resolve, work through the following questions to identify the root cause. - Is the record type definitely CNAME? Log back in to your DNS provider and confirm. It is easy to accidentally save as an A record if the default option in your provider's form is pre-selected. - Is the CNAME value exactly what Search Atlas provided? Go back to your White Label settings in Search Atlas and copy the hostname again. Paste it fresh rather than retyping. - Has it been less than 48 hours? If so, continue waiting and recheck using the DNS lookup tool rather than your browser. - Is there a proxy or CDN layer in front of the domain? If you use Cloudflare, make sure the CNAME record is set to DNS Only (grey cloud icon), not Proxied (orange cloud), during initial setup. Proxied mode can interfere with domain verification. - Did you add the CNAME at the root domain level? Root-level CNAMEs (for example, agencypro.com without a subdomain) are not supported by most DNS providers and are not compatible with Search Atlas White Label. You must use a subdomain such as reports.agencypro.com. 🔧 Quick Checklist Before Contacting Support - Record type is CNAME (not A, AAAA, or TXT) - CNAME value matches exactly what is shown in Search Atlas White Label settings - No conflicting A records or duplicate CNAMEs exist for the same subdomain - At least 4 hours have passed since the last change - DNS lookup tool confirms the CNAME is resolving to the correct target - Cloudflare proxy is disabled (grey cloud) if applicable - A subdomain is used, not the root domain 💬 Still Need Help? If you have completed every step above and the DNS is still not resolving, our team can review your specific configuration. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. Additional Notes A previous version of our guidance incorrectly instructed customers to create an A record pointing to IP address 35.243.150.225. This is outdated and incorrect. Do not use that IP. Also, the correct CNAME target is whitelabel.dns.searchatlas.com (not whitelabel.searchatlas.com). Delete any existing A record pointing to 35.243.150.225.

Last updated on Oct 26, 2026

⚠️ "You Do Not Have Access to Update Settings" Error After Saving White Label Domain

After you save a new White Label domain and open the Settings tab without refreshing, clicking Update Settings shows "You do not have access to update settings." Your permissions are correct, and a single page refresh resolves it immediately. This guidance applies to the current White Label setup workflow. A revised setup workflow (Linear WL-291, Awaiting Release) is planned that changes how setup errors are handled and introduces a different error message. Until that update ships, the steps below apply to the session-sync error described here. 💡 Why the Update Settings Error Appears When you save a new White Label domain, Search Atlas updates your account's permission state in the background. If you open the Settings tab before the browser session syncs those updated permissions, the Update Settings button cannot verify your access and returns this error. Your account permissions are not affected. This is a temporary session state mismatch, not a real access restriction. 🛠️ How to Fix the Update Settings Error 1. After saving your White Label domain, press F5 (Windows) or Cmd + R (Mac) to refresh the page, or click your browser's reload button. 2. Open the Settings tab. 3. Click Update Settings. The error no longer appears, and your changes save successfully. 💡 How to Avoid the Update Settings Error Refresh the page immediately after saving a new White Label domain, before opening any other tab. This lets the browser session pick up your updated permission state before you make further changes in Settings. 🛠️ What to Do If You See "Failed to Update Brand Setting" If you instead see a "Failed to update brand setting" error rather than the access error above, the domain you entered may already be in use. This is a separate issue from the session sync mismatch and is not resolved by refreshing the page. Contact support to verify the domain's availability. 🔗 Related White Label Issues If your White Label logo doesn't display on the login screen, or you encounter other login screen display problems, see the companion White Label logo and login screen troubleshooting guide for complete coverage. 🎯 You now know that the "You do not have access to update settings" error is a session sync issue, not a real permissions problem, and a single page refresh resolves it immediately. For a full walkthrough of White Label configuration, see the White Label Domain Setup guide.

Last updated on Oct 26, 2026

🌐 White Label Subdomain DNS and CNAME Setup

🗺️ Overview Setting up a white label subdomain lets you present Search Atlas reports and dashboards under your own brand. This requires adding specific DNS records to your domain. One of the most common points of confusion is understanding which record types are needed and how to configure them correctly with your DNS provider. If you are running into issues with your white label subdomain not resolving, our support team can review your specific configuration and guide you through the correct setup. 📋 What DNS Records Do You Need? White label subdomain setup involves adding DNS records to your domain. The exact record type and target value required for your account will be confirmed by the Search Atlas support team, as configuration details vary by account. Before reaching out, it helps to have the following information ready: - The subdomain you intend to use (e.g., reports.youragency.com) - Your DNS provider (e.g., Cloudflare, GoDaddy, Namecheap, Route 53) - Any error messages you are seeing in your DNS provider's control panel or in the Search Atlas platform - A screenshot or description of any existing records on that subdomain ⚙️ General Steps to Add a DNS Record 1. Log in to your DNS provider's control panel. 2. Navigate to the DNS settings for your domain. 3. Add the record type and value as instructed by the Search Atlas support team. 4. Save the record and allow time for DNS propagation. ☁️ Common Issues with Cloudflare If you are using Cloudflare as your DNS provider and are encountering errors when saving or activating your white label subdomain record, open the chat widget in the bottom-right corner of the platform and type human teammate to reach our support team. Provide the exact error message displayed in Cloudflare and the current state of your DNS records so our team can advise on the correct configuration for your setup. 🔍 What to Have Ready When You Contact Support - Your Search Atlas account email or project name - The subdomain you are trying to configure - Your DNS provider name - The exact error message you are seeing (copy and paste it if possible) - A description or screenshot of your current DNS records for that subdomain If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🛠️ Fix Whitelabel DNS Setup and OTTO Redeployment

🔍 Overview After upgrading your Search Atlas plan and configuring a whitelabel subdomain, you may see OTTO Not Deployed warnings on your projects and Access Forbidden errors when visiting your custom domain. This happens because a plan upgrade resets certain platform-level settings, and your DNS records or OTTO activation may need to be reapplied. Follow the steps below to resolve both issues. ⚙️ Step 1: Verify Your DNS Records Are Correctly Configured Before redeploying OTTO, confirm that your subdomain (for example, dashboard.mindshiftdigital.co) is pointing to Search Atlas correctly. Log in to your domain registrar or DNS provider and check that the following records exist: - Type: CNAME - Host / Name: your chosen subdomain prefix (e.g., dashboard) - Value / Points to: the CNAME target provided in your Search Atlas whitelabel settings - TTL: 3600 (or the lowest value your provider allows) If you have an existing A record for the same subdomain, remove it before adding the CNAME. Conflicting records are the most common cause of Access Forbidden errors. DNS changes can take up to 48 hours to fully propagate, but most providers update within 1–4 hours. 🌐 Step 2: Confirm Your Whitelabel Settings Inside Search Atlas Once DNS is pointing correctly, verify your whitelabel configuration inside the platform: 1. Click the apps-grid icon in the header and select More Features. 2. Open Agency Hub (Set up your Agency's White Label). 3. Confirm your custom subdomain is entered exactly as configured in your DNS (e.g., dashboard.mindshiftdigital.co). 4. If the field is blank or shows a previous domain, re-enter your subdomain and click Save. 5. Wait a few minutes, then visit your subdomain in a new browser tab to confirm the Access Forbidden error is resolved. If you see a security certificate warning instead of an Access Forbidden error, SSL provisioning is still in progress. Wait up to 30 minutes and refresh. 🚀 Step 3: Redeploy OTTO on Each Affected Project A plan upgrade can deactivate OTTO across your projects. You will need to redeploy it manually for each project showing OTTO Not Deployed. Here is how: 1. Go to OTTO SEO in the left sidebar and open SEO Automation (or navigate to /seo-automation-v3). 2. Select the first project showing OTTO Not Deployed. 3. Click the OTTO tab or the Deploy OTTO button on the project dashboard. 4. Follow the on-screen prompts to connect OTTO to the project's website. If the site uses WordPress, ensure the Search Atlas plugin is installed and the API key is current. 5. Once deployment completes, the status will change to OTTO Active. 6. Repeat these steps for every additional project that shows the Not Deployed status. Important: If your OTTO pixel was previously installed via a third-party tag manager (such as Google Tag Manager), verify that the pixel snippet in your tag manager still matches the one shown in your current OTTO settings. Plan upgrades can generate a new pixel ID that must be re-pasted into your tag manager container and published. 🔎 Step 4: Clear Cache and Test After completing DNS verification and OTTO redeployment, take the following steps to confirm everything is working: - Clear your browser cache or open an incognito window before testing your whitelabel subdomain. - If your site uses a caching plugin (e.g., WP Rocket, W3 Total Cache), purge the cache from the plugin dashboard. - Visit your whitelabel subdomain and confirm the Search Atlas interface loads without errors. - Return to OTTO SEO in the left sidebar and open All Sites (SEO Automation) to confirm all projects display OTTO Active. ⚠️ Common Issues and Quick Fixes - Access Forbidden after DNS update: Double-check there are no duplicate or conflicting A records for the same subdomain at your registrar. - OTTO Not Deployed reappears after saving: Ensure your WordPress plugin is updated to the latest version and the API key in the plugin settings matches your Search Atlas account. - SSL certificate error on subdomain: Wait up to 30 minutes for auto-provisioning. If the error persists beyond an hour, the CNAME record may not be fully propagated yet. - Only one project redeployed but others still show Not Deployed: OTTO must be redeployed per project — there is no bulk-deploy option. Repeat Step 3 for each project individually. 💬 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.

Last updated on Oct 26, 2026

🛠️ How to Report Bugs: Whitelabel vs Standard Domain

🔍 Understanding Your Two Access Points Search Atlas can be accessed in two ways depending on your account type: - Standard domain: You log in directly at the official Search Atlas URL (e.g., app.searchatlas.com). - Whitelabel domain: You log in through a custom-branded URL set up by your agency or reseller (e.g., app.youragency.com). Both access points connect to the same underlying platform, but knowing which one you were using when the bug occurred is critical for our team to reproduce and resolve the issue quickly. ⚠️ Why This Matters for Bug Reports Bugs can behave differently depending on the login method and domain used. For example, a layout issue or broken feature may appear only on a whitelabel domain due to custom branding settings, or only on the standard domain due to account-level configurations. Reporting the wrong URL can delay diagnosis and resolution. ✅ How to Identify Which Domain You Are Using Before submitting a bug report, check the following: 1. Look at your browser's address bar while you are logged in. 2. If the URL contains searchatlas.com, you are on the standard domain. 3. If the URL contains a custom domain (your agency or company name), you are on a whitelabel domain. 4. Take note of the exact URL — copy it directly from the address bar. 📋 What to Include in Your Bug Report To help our team investigate efficiently, always include the following details when reporting a bug: - The full URL where the bug occurred (copied directly from your browser's address bar). - The login method used: standard Search Atlas domain or whitelabel domain. - Your account email address associated with the affected login. - Steps to reproduce the bug: a numbered list of exactly what you did before the issue appeared. - What you expected to happen versus what actually happened. - Screenshots or screen recordings if possible — these significantly speed up resolution. - Browser and device information: browser name, version, and whether you are on desktop or mobile. 🚀 How to Submit Your Bug Report Follow these steps to submit your report correctly: 1. Log in to the platform using the same domain where the bug occurred — either the standard Search Atlas URL or your whitelabel URL. 2. Reproduce the bug if possible so you can capture the exact URL and any error messages. 3. Open the chat widget in the bottom-right corner of the platform. 4. Type human teammate to be connected with a member of our team. 5. Share all the details listed in the section above. 💡 Quick Tips to Avoid Confusion - Always report bugs from the same domain where you experienced the issue. Do not switch to the other domain before contacting support. - If you have access to both a whitelabel panel and the standard Search Atlas domain, test whether the bug appears on both — this helps narrow down the root cause. - If you are a reseller reporting on behalf of a client, confirm which URL your client was using at the time of the issue before reaching out. 🙋 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.

Last updated on Oct 26, 2026

🛠️ Fix White-Label Report Showing OTTO Name

🔍 What's Happening If you've configured a custom name for OTTO SEO in your white-label settings — for example, Harvey or Evo — you may notice that some reports still display OTTO SEO instead of your chosen name. This is a known issue that affects white-labeled reports. ⚙️ Why This Occurs When you set a white-label product name in your settings, most of the platform updates to reflect your custom branding. However, certain areas of the Report Builder contain hardcoded references to OTTO SEO that are not yet fully connected to your white-label configuration. Our development team is actively working to ensure every reference across the platform respects your white-label name. 📋 Known Affected Areas Reports generated through the Report Builder may currently display the default name instead of your custom one. If you encounter this issue, please note the specific report sections affected so our team can investigate further. 🚀 Current Fix Status Our engineering team is aware of this issue and is actively working on a fix. Additional fixes targeting the Report Builder are currently in development and will be released as they become available. 🛠️ What You Can Do Now While the permanent fix is being completed, follow these steps to minimize the impact on your client deliverables: 1. Verify your white-label name is saved correctly. Check your white-label settings and confirm your custom product name is entered and saved properly. Even if some reports don't reflect it yet, this ensures the name propagates once fixes are released. 2. Regenerate your reports. After confirming your settings, generate a fresh report from the Report Builder. Some sections may already reflect your white-label name correctly. 3. Review reports before client delivery. Always preview your report and use the find feature to search for any remaining references to OTTO before sending. 💬 Still Need Help? We understand that branding consistency is critical for your client deliverables. If you are experiencing this issue, please reach out with your project name, the specific report sections where OTTO SEO still appears, and screenshots of the affected report so our team can assist you further. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🛠️ Fix White-Label DNS and Team Invitation Issues

🔍 Overview White-label setup in Search Atlas lets you present the platform under your own brand and custom domain. When DNS is misconfigured, team member invitation links can break or fail to load. This article walks you through the correct DNS setup, how to connect an alternative host, and how to fix invitation link issues. ⚙️ How White-Label DNS Works When you enable white-label, Search Atlas maps your custom domain (for example, reports.yourdomain.com) to the Search Atlas platform. For this to work, your domain's DNS records must point to the correct destination. If these records are missing, incorrect, or haven't propagated yet, any links generated under your white-label domain — including team member invitations — will not resolve properly. 🚀 Step 1: Configure Your DNS Records Log in to your domain registrar or DNS provider (for example, Cloudflare, GoDaddy, or Namecheap) and add the following record: - Record type: CNAME - Host / Name: The subdomain you want to use (for example, reports) - Points to / Value: The target address provided in your Search Atlas white-label settings - TTL: 3600 (or Auto) Save the record. DNS propagation typically takes between 15 minutes and 48 hours depending on your provider and previous TTL values. 🔗 Step 2: Enter Your Custom Domain in Search Atlas 1. Log in to Search Atlas and go to your Account Settings. 2. Navigate to the White Label section. 3. Enter your full custom domain in the Custom Domain field (for example, reports.yourdomain.com). 4. Click Save or Verify Domain. 5. Wait for the platform to confirm that the domain has been verified successfully. If verification fails, double-check that your CNAME record matches the target address shown on screen exactly. 🌐 Step 3: Connect an Alternative Host If you need to use a different hosting provider or DNS manager than your primary domain registrar, follow these steps: 1. Log in to your alternative DNS provider and create a new CNAME record using the same values described in Step 1. 2. If your domain is currently managed by another provider, update your domain's nameservers to point to the new host, or add the CNAME record directly at the registrar level without changing nameservers (this is usually the simpler option). 3. Return to Search Atlas white-label settings and re-enter your custom domain, then click Verify Domain again once propagation is complete. Tip: Use a free tool like dnschecker.org to confirm your CNAME record has propagated across global DNS servers before retrying verification. 📧 Step 4: Resend Team Member Invitations Once your domain is verified and DNS has fully propagated, any previously sent invitation links that used the broken domain will no longer work. You must resend invitations so they are generated under the now-active white-label domain. To do this: 1. Go to Account Settings and open the Team Members section. 2. Locate the team member whose invitation did not work. 3. Click Resend Invitation next to their name. 4. Ask the team member to check their inbox (and spam folder) for the new link and follow the instructions to accept the invitation. ⚠️ Common Issues and Fixes - Invitation link shows a "site can't be reached" error: DNS has not propagated yet, or the CNAME record is missing. Verify the record at your DNS provider and wait up to 48 hours. - Domain verification fails in Search Atlas: Ensure there are no extra spaces in the CNAME value and that no conflicting A records exist for the same subdomain. - Team member receives the invitation but cannot log in: The domain may be verified but SSL is still being provisioned. Wait 10–15 minutes and try again. - Using Cloudflare: Set the CNAME record proxy status to DNS only (grey cloud icon) rather than proxied (orange cloud). Proxying can interfere with SSL certificate provisioning on Search Atlas's end. 💡 Tips for a Smooth Setup - Use a dedicated subdomain (for example, seo.youragency.com) rather than your root domain to avoid conflicts with your main website. - Complete DNS setup and domain verification before inviting team members to avoid broken links. - If you manage multiple client workspaces, each workspace can have its own white-label domain — repeat this process for each one. 🙋 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.

Last updated on Oct 26, 2026

🛠️ Fix White Label DNS Setup and Form Errors

🌐 What Is White Label DNS Configuration? White label DNS configuration lets you serve Search Atlas reports and dashboards under your own custom domain or subdomain. When set up correctly, your clients see your brand — not Search Atlas. If any step is missed or a DNS record is entered incorrectly, you may encounter form submission errors or see the setup fail to verify. 📋 Prerequisites Before You Begin - Access to your domain registrar or DNS provider (e.g., GoDaddy, Cloudflare, Namecheap). - A subdomain chosen for white label use (e.g., reports.yourdomain.com). - Admin-level access to your Search Atlas account. - A verified sender email address for client-facing communications. ⚙️ Step-by-Step DNS Setup 1. Log in to Search Atlas and navigate to your white label settings via More Features → Agency Hub (Agency Settings). 2. Enter your custom subdomain in the designated field (e.g., reports.yourdomain.com). Do not use your root domain — a subdomain is required. 3. Copy the CNAME record provided by Search Atlas. It will look similar to: whitelabel.dns.searchatlas.com. 4. Log in to your DNS provider and create a new CNAME record: - Name/Host: your subdomain prefix (e.g., reports) - Value/Target: the CNAME value copied from Search Atlas - TTL: 3600 (or Auto if available) 5. Save the DNS record and return to Search Atlas. 6. Click Verify or Save on the white label setup form to trigger DNS verification. ⏱️ How Long Does DNS Propagation Take? DNS changes can take anywhere from a few minutes to 48 hours to propagate globally. In most cases, propagation completes within 1–4 hours. If verification fails immediately after saving, wait at least 30 minutes before trying again. Do not repeatedly click Verify in quick succession, as this can trigger rate-limiting. 🚨 Troubleshooting Form Submission Errors If you receive a form submission error during white label setup, work through the following checks before contacting support: - Check for typos in the subdomain field. The subdomain must exactly match the Name/Host value you entered in your DNS provider. Even a single extra character will cause verification to fail. - Confirm the CNAME record is active. Use a free DNS lookup tool (such as MXToolbox or dnschecker.org) to confirm your subdomain resolves to the correct CNAME target. - Avoid using a root domain. Entering yourdomain.com instead of a subdomain like reports.yourdomain.com is a common cause of errors. Always use a subdomain. - Remove any conflicting A records. If an A record already exists for the same subdomain in your DNS provider, it will conflict with the CNAME. Delete or rename the conflicting record first. - Check Cloudflare proxy settings. If your domain is managed through Cloudflare, make sure the CNAME record is set to DNS only (grey cloud icon), not Proxied (orange cloud). The proxied setting can block verification. - Clear your browser cache and try submitting the form again in a private or incognito window. - Verify your account permissions. Only account admins can complete white label setup. If you are on a sub-account or team seat, ask your account owner to complete this step. ✅ How to Confirm Setup Is Complete Once DNS verification succeeds, you will see a confirmation message in the white label settings. You can then: - Visit your custom subdomain in a browser to confirm it loads the correct branded interface. - Send a test report link to yourself to verify the client-facing experience looks correct. - Review your logo, brand colours, and sender name to ensure everything matches your brand. 💡 Common Mistakes to Avoid - Adding http:// or www to the subdomain field — enter only the subdomain, with no protocol prefix. - Setting TTL too low (under 300 seconds) on critical DNS records, which can cause intermittent failures. - Forgetting to save changes in your DNS provider before returning to Search Atlas to verify. 🤝 Need More Help? If you have followed all the steps above and are still experiencing a form submission error or DNS verification failure, our team is 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.

Last updated on Oct 26, 2026

🛠️ White Label Setup: Cloudflare DNS and GHL Blog

🌐 Overview Setting up Search Atlas white labeling with a custom domain involves three moving parts: your Cloudflare DNS record, the Search Atlas white label configuration, and any third-party integrations such as GoHighLevel (GHL) blogs or the WordPress plugin. A misconfiguration in any one of these areas can cause broken dashboard URLs or content display issues. This guide walks you through each step in the correct order. ⚙️ Step 1: Configure Your White Label Domain in Search Atlas Before touching DNS, make sure your custom domain is registered inside Search Atlas. 1. Log in to your Search Atlas account and navigate to Settings → White Label. 2. Enter your chosen subdomain (e.g., app.youragency.com) in the custom domain field. 3. Save the settings. Search Atlas will display the CNAME target value you need for the next step. Copy this value exactly — do not modify it. Important: Complete this step first. Creating the DNS record before registering the domain in Search Atlas is a common cause of mismatches that break the dashboard URL. ☁️ Step 2: Add the CNAME Record in Cloudflare 1. Log in to Cloudflare and select the domain you are using for white labeling. 2. Go to DNS → Records and click Add record. 3. Set the record type to CNAME. 4. In the Name field, enter only the subdomain prefix (e.g., app if your full subdomain is app.youragency.com). 5. In the Target field, paste the CNAME value copied from Search Atlas. 6. Set Proxy status to DNS only (grey cloud). Enabling the Cloudflare proxy (orange cloud) on this record is the most frequent cause of broken dashboard URLs because it intercepts SSL termination handled by Search Atlas. 7. Click Save. DNS propagation typically takes 5–30 minutes, but can take up to 48 hours in some regions. Use a tool such as dnschecker.org to confirm the CNAME is resolving correctly before proceeding. 🔌 Step 3: Fix the WordPress Plugin Dashboard URL If you added the DNS record after the WordPress plugin was already installed, the plugin may still be pointing to the original Search Atlas dashboard URL instead of your white label domain. 1. In your WordPress admin panel, go to Search Atlas → Settings. 2. Locate the Dashboard URL or API Endpoint field. 3. Replace the existing URL with your new white label domain (e.g., https://app.youragency.com). 4. Save changes and reload the plugin page to confirm the connection is successful. If the field is greyed out or the plugin re-populates the old URL automatically, deactivate and reactivate the plugin after updating the URL, then save again. 📝 Step 4: Fix Missing Tables in GHL Blog Posts GoHighLevel's blog editor strips certain HTML elements — including table tags — when content is pasted or imported. This is a known GHL editor limitation, not a Search Atlas issue. Use one of the following workarounds to display tabular data correctly: - Convert tables to styled lists or columns: Recreate the table content using GHL's native column blocks or bullet lists so the editor does not strip the markup. - Embed an HTML block: In the GHL blog editor, insert a Custom Code / HTML block and paste your raw table HTML directly into it. This bypasses the editor's sanitisation and renders the table as intended. - Use an image: For purely visual tables (non-interactive data), export the table as an image and insert it via GHL's image block. Recommended approach: The HTML block method preserves full formatting and is the most reliable option for complex tables. ✅ Quick Troubleshooting Checklist - Dashboard URL broken after DNS change? Confirm the CNAME proxy is set to DNS only in Cloudflare and that the target matches the value in Search Atlas Settings. - WordPress plugin connecting to wrong URL? Manually update the Dashboard URL field in the plugin settings to your white label domain. - SSL certificate errors on white label domain? Wait up to 30 minutes after DNS propagation for the certificate to provision automatically. Do not enable the Cloudflare proxy during this window. - Tables still not showing in GHL? Switch to an HTML block and paste the raw table markup directly. 💬 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.

Last updated on Oct 26, 2026

🏦 Troubleshooting Brand Vault Incomplete Status

This article helps you resolve a situation where your Brand Vault appears incomplete despite having filled in every field you can see. The most common cause is a field that was skipped, left in a draft-like state, or not formally saved — even though it looks filled in visually. Because Brand Vault completion is validated field by field, a single unsaved or partially completed entry can prevent the vault from registering as complete. 📍 Where to Find It Access your 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 → open your project → Brand Vault. If you have not created one yet for this project, use the Create Brand Vault option once inside. 🛠️ Step-by-Step 1. Open your Brand Vault via top-right More Features menu (grid icon, next to your Avatar Menu (👤)) → Brand Vault, or OTTO SEO in the left sidebar → All Sites → open your project → Brand Vault. 2. Scroll through every section from top to bottom — do not skip any. Sections may include brand name, logo, colors, typography, tone of voice, and target audience details. 3. For each field, click directly into it and confirm the content is active, not just visually present. Some fields require you to click into them to register as touched. 4. Pay close attention to optional-looking fields such as color hex codes, font selections, or dropdown menus — these are sometimes required for completion validation even if they appear optional. 5. If any field has a placeholder, default value, or appears faded, replace or re-enter the value and confirm your selection. 6. After reviewing all fields, locate and click the Save or equivalent confirmation button at the bottom of the vault form to ensure all entries are formally submitted. 7. If the vault still shows incomplete after saving, try refreshing the page and re-opening the Brand Vault to force the system to re-evaluate completion status. ✅ How to Confirm It Worked After saving, your Brand Vault status indicator should update to reflect a complete state — this typically appears as a filled progress bar, a checkmark, or the removal of any incomplete warning banners on the Brand Vault page. If you previously saw a message such as "incomplete" or a progress percentage below 100%, re-open the vault and confirm that message is no longer present. If the status still does not update after a page refresh, this may indicate a field-level validation issue that requires a support review of 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.

Last updated on Oct 26, 2026

🌐 Reconfigure White Label DNS After Nameserver Migration

🔍 Overview When you migrate your nameservers from a registrar like GoDaddy to Cloudflare, all existing DNS records are not automatically carried over. This causes both your main website and your Search Atlas White Label dashboard to go offline until the correct DNS records are re-created. This article explains what information to have ready so our support team can provide you with the exact DNS values for your account. ⚠️ Why Both Systems Go Down Your White Label dashboard runs on a subdomain of your domain (for example, reports.yourdomain.com). When you switch nameservers, Cloudflare starts serving DNS for your domain from scratch. Unless you manually add the required records in Cloudflare, neither your website nor your White Label dashboard will resolve correctly. 📋 What You Will Need Before Starting - Access to your Cloudflare account and the DNS settings for your domain - Your Search Atlas account with White Label already configured - The subdomain you chose for your White Label dashboard (for example, reports.yourdomain.com) - Your website's original hosting IP address (check your old registrar or hosting provider if unsure) 🛠️ Step 1 — Restore Your Website's DNS Records in Cloudflare You will need to re-add the DNS records for your root domain and www subdomain in Cloudflare, pointing them to your website's hosting IP address. Use the IP address provided by your hosting provider — not a Search Atlas IP. Refer to your Cloudflare account's DNS management section to add these records. 🏷️ Step 2 — Add the Search Atlas White Label DNS Record Your White Label dashboard must point to Search Atlas via a CNAME record on your chosen subdomain (a root domain cannot be used). The recommended settings for your White Label subdomain are provided by Search Atlas support. To get the exact DNS values for your account, contact our support team and have the following ready: - Your domain name - The subdomain prefix you chose for your White Label dashboard (for example, reports) - Confirmation that your nameservers have been successfully migrated to Cloudflare ⏳ Step 3 — Allow Time for DNS Propagation After adding or updating your DNS records, changes can take anywhere from a few minutes to 48 hours to fully propagate across the internet. During this time your website or White Label dashboard may intermittently appear offline or show SSL errors. This is normal. You can use a tool such as whatsmydns.net to monitor propagation status for your domain. ✅ Summary Nameserver migrations require you to manually re-create all DNS records in Cloudflare. Your website records should point to your hosting provider's IP, and your White Label subdomain record must point to the IP address that Search Atlas support provides for your specific account. Do not attempt to guess or copy a generic IP for the White Label record, as incorrect values will prevent your dashboard from loading even after propagation completes. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🔧 Fix Otto Pixel Errors After Whitelabel Setup

Overview When you upgrade your Search Atlas plan or configure a whitelabel subdomain, your Otto pixel becomes tied to a new URL environment. Any previously installed pixels are no longer valid for that domain, which causes "Otto not deployed" and "Access forbidden" errors across your projects. The fix requires you to regenerate your Otto pixel inside the platform and redeploy it to each site under your new whitelabel subdomain. When Pixel Regeneration Is Required You must regenerate and redeploy your Otto pixel any time one of the following changes occurs: - You upgrade to a new Search Atlas plan - You set up or change a whitelabel subdomain - You transfer projects to a different whitelabel environment - Your current pixel was generated before your whitelabel subdomain was fully activated In all of these cases, the old pixel references the previous domain and will not authenticate correctly against the new whitelabel URL, triggering the errors you are seeing. Step 1 — Confirm Your Whitelabel Subdomain Is Active Before regenerating your pixel, make sure your subdomain is fully propagated and reachable. 1. Open a browser and navigate to your whitelabel subdomain. 2. Confirm the Search Atlas login screen loads without errors. If it does not load, your DNS records may still be propagating — allow sufficient time after initial setup for propagation to complete. 3. Log in through your whitelabel subdomain URL, not through the default Search Atlas domain. All steps below must be completed while logged in via your whitelabel URL to ensure the pixel is generated for the correct environment. Step 2 — Regenerate Your Otto Pixel 1. Log in to the platform via your whitelabel subdomain URL. 2. Navigate to OTTO SEO → All Sites (SEO Automation). 3. Select the project that is showing "Otto not deployed." 4. Locate the pixel or deployment option within the project and use the available control to generate a new pixel script. The platform will produce a fresh pixel tied to your active whitelabel subdomain. 5. Copy the full pixel code snippet that appears. Do not close this screen until you have successfully installed the code in the next step. Step 3 — Redeploy the Pixel to Your Site 1. Log in to the WordPress admin panel (or your site's CMS) for the project you are working on. 2. Navigate to the location where your previous Otto pixel was installed. This is typically inside a header script field, a dedicated Otto plugin settings page, or a custom code snippet area. 3. Replace the old pixel code with the new pixel code you copied in Step 2. 4. Save your changes and clear any site or server caches. 5. Return to the platform and verify that the project now shows Otto as deployed. If it still shows an error, wait a few minutes and refresh the page before troubleshooting further. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🔗 Fix White-Label Report Share URL Issues

🔍 Overview When you click Share URL inside the Report Builder, the generated link should use your agency's custom white-label domain — not dashboard.searchatlas.com. If you are seeing a Search Atlas domain in your shareable links, this article explains why it happens and how to resolve it. ⚙️ Why This Happens There are two common reasons the wrong URL is generated: - No custom domain is configured: If your white-label custom domain has not been set up or saved correctly in your account settings, the platform falls back to the default Search Atlas domain when generating share links. - A previous platform bug: A known issue caused the Report Builder to resolve shareable and iframe URLs to dashboard.searchatlas.com even when a custom domain was correctly configured. This bug has been fixed in a recent platform update. If you were affected before the fix, you will need to regenerate your share links to get the correct URL. ✅ How to Fix It 1. Go to Left sidebar → Reports (URL: /report-builder/projects-list). 2. Verify that your white-label custom domain is active. If you are unsure, check your white-label settings in your account — your custom domain must be saved and verified before share links will use it. 3. Open the report you want to share. 4. Click Share URL to generate a fresh link. 5. Confirm the generated URL now shows your agency's custom domain, not dashboard.searchatlas.com. 6. Copy the new link and share it with your client. Any previously copied links using the old domain will need to be replaced with the newly generated ones. 🛠️ If the URL Still Shows the Wrong Domain If you have regenerated the link and it still resolves to dashboard.searchatlas.com, work through the following checks: - Confirm your custom domain is saved: Navigate to your white-label settings and ensure your agency domain is entered correctly and marked as active. An incomplete or unverified domain will cause the fallback URL to appear. - Clear your browser cache: In rare cases, a cached version of the page can display stale link data. Clear your cache and reload the Report Builder before generating a new link. - Try a different browser or incognito window: This rules out browser extensions or cached data interfering with the generated URL. - Re-save your white-label domain settings: Open your white-label configuration, re-enter your custom domain, and save again. Then return to the Report Builder and generate a new share link. 📋 Key Points to Remember - Any share links generated before the bug fix was deployed may still contain the old Search Atlas domain. These links will not automatically update — you must generate new ones. - Iframe embed links are affected in the same way. If you use embedded reports on a client portal, regenerate those URLs as well. - A correctly configured white-label custom domain is required for the share link to reflect your agency branding. The platform cannot generate a custom-domain URL if no domain has been set. 💬 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.

Last updated on Oct 26, 2026

Fix White-Label Report URLs Redirecting to Registration

🔍 What Is This Issue? If your white-label report share links or iframe URLs are redirecting visitors to a registration or login page instead of displaying the report, you have encountered a known recurring bug in the white-label reporting system. This issue can affect both shared report links and embedded iframe reports sent to your clients, and it has been reported to resurface on a monthly basis. This article explains what is happening and what to have ready when you contact our team to get it resolved. ⚠️ Why Does This Happen? This is a known recurring bug in the white-label reporting system. The underlying cause is handled on the backend and cannot be resolved through settings changes on your end. Because it recurs monthly, you may experience this issue again even after a previous fix. 🛠️ What to Do Because this is a backend bug, our support team will need to investigate and apply the fix on your account directly. To help us resolve it as quickly as possible, please have the following ready before reaching out: - Your white-label domain or subdomain — the custom URL you use for client-facing reports. - The specific report share link or iframe URL that is redirecting incorrectly. - The date and time you first noticed the redirect, including your timezone. - Whether this has happened to you before — note approximately when the previous occurrence was if known. - Any affected client names or project names associated with the redirecting reports. Having these details ready will allow our team to locate the issue on the backend and apply the fix without unnecessary back-and-forth. 📋 What to Expect Once our team applies the backend fix, your white-label report URLs and iframe embeds should return to displaying correctly. Because this bug is known to recur, please contact us again if you experience the redirect issue in a future month — each recurrence requires a backend 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.

Last updated on Oct 26, 2026

🔑 Fix White Label Account Access and OTTO Upgrades

🔍 Overview If you manage white label customer accounts inside Search Atlas, you may run into two common issues: being unexpectedly logged out when accessing a customer's account, and uncertainty about which plan to assign so the customer can use OTTO SEO. This article explains both issues and walks you through the steps to resolve them. ⚙️ Why You Keep Getting Logged Out When you access a white label customer's account, Search Atlas treats the session as a separate login. Getting kicked out typically happens for one of the following reasons: - Simultaneous sessions: The customer is actively logged in at the same time you are. The platform allows only one active session per account, so one user will be pushed out. - Session timeout: Customer accounts may have shorter inactivity timeouts depending on their plan settings. If you step away, the session can expire. - Browser conflicts: Accessing multiple white label accounts in the same browser window can cause session collisions. Different accounts share the same cookie space unless you use separate browser profiles or incognito windows. To avoid being logged out, follow these best practices: 1. Coordinate with your customer before accessing their account so you are not both logged in at the same time. 2. Use a dedicated browser profile or an incognito window for each white label customer account you manage. 3. Avoid leaving customer account sessions idle for long periods. 🚀 Which Plan Gives Customers OTTO Access OTTO SEO is available on specific plans within Search Atlas. To enable OTTO for a white label customer, the customer's account must be assigned a plan that includes OTTO SEO as a feature. Here is how to check and update a customer's plan: 1. Log in to your main Search Atlas account (your agency account, not the customer's). 2. Navigate to your Avatar Menu (👤) by clicking your avatar in the top-right corner. 3. Select Team Members or your white label client management area from the dropdown. 4. Locate the customer account you want to upgrade. 5. Review the plan currently assigned to that customer. If the plan does not include OTTO SEO, select an upgraded plan that lists OTTO SEO as an included feature. 6. Save your changes. The customer will now have OTTO SEO available in their account. Important: If you are unsure which plan tier includes OTTO SEO for white label customers, or if the upgrade option is not visible in your dashboard, this may be a billing or permissions configuration that requires manual adjustment by the Search Atlas team. 🛠️ Quick Troubleshooting Checklist Run through this checklist before escalating to support: - Still getting logged out? Confirm the customer is not logged in at the same time, and switch to a separate browser profile. - OTTO not visible after upgrade? Ask the customer to log out and log back in to refresh their session and plan entitlements. - Upgrade option missing? Verify you are logged into your agency (parent) account, not the customer's account, when managing plans. - Customer cannot see OTTO tools? Check that OTTO SEO is explicitly listed as an included feature on their assigned plan, not just that they are on a higher-tier plan. 💡 Tips for Managing Multiple White Label Accounts - Use a password manager to store unique credentials for each customer account so switching between them is fast and error-free. - Label each browser profile clearly (for example, "Client A — Search Atlas") to avoid accidentally working in the wrong account. - Keep a simple internal record of each customer's current plan and feature set so you can quickly identify who needs an upgrade. 📊 Still Seeing Issues? If you have followed all the steps above and the problem persists — whether that is repeated logouts, OTTO not appearing after an upgrade, or plan changes not taking effect — our team can investigate the specific account configuration for you. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🛠️ Fix White-Label Report URL Redirect Issues

🔍 Overview Some agency users on Search Atlas experience a recurring issue where their white-label report URL redirects visitors to the Search Atlas register page instead of staying on the custom agency domain. This article explains why this happens and what to have ready when you contact support to get it resolved. ⚠️ What Is Happening When a white-label report link is shared with a client, the link should open inside your branded agency domain — not redirect to a generic Search Atlas registration page. This redirect bug has been reported on a recurring monthly basis and is resolved through a backend action by the Search Atlas team. It is not something customers can fix on their own through account settings. 🔄 Why This Issue Recurs This redirect issue has been reported on a recurring basis. It is caused by a platform-side bug that affects white-label URL routing for certain agency accounts. The engineering team is aware of this pattern and is working on a permanent fix. When it occurs, the resolution requires action from our support or engineering team on the backend. 📋 What to Have Ready When You Escalate To help our team resolve this as quickly as possible, please have the following information ready before reaching out: - Your agency account email address. - The exact white-label report URL that is redirecting incorrectly. - The date and approximate time you first noticed the redirect. - A brief description of whether this has happened to your account before and roughly when. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🛠️ Fix Whitelabel Registration and Invitation Errors

🔍 What Is This Error? If your clients visit your whitelabel domain (for example, audit.fencemarketingpros.com) and see a message asking them to register or be invited, it means the invitation or account link between your agency and that client account is broken or incomplete. This can happen even if the client previously had access. Common scenarios that trigger this error include: - A client clicking an expired or already-used invitation link - An invitation that was sent but never fully completed by the client - A client who is already registered clicking an invite link again, which leads to a broken flow instead of redirecting to the login page - A technical issue during the invitation send process (such as a 500 error in the background) - A reCAPTCHA screen blocking the invite flow from completing ⚙️ How to Diagnose the Problem Before taking action, identify which situation applies to your client: 1. Ask the client whether they have ever successfully logged into the whitelabel portal before. 2. Check whether the client was sent an invitation recently or if the link they are using is old. 3. Confirm whether the client completed the registration step after receiving the invite email, or if they abandoned it partway through. ✅ Step-by-Step Fix Follow these steps to restore your client's access to the whitelabel portal: 1. Log in to your Search Atlas account. 2. Navigate to More Features → Agency Hub (URL: /agency-settings). 3. Locate the client account experiencing the error in your client list. 4. If the client appears as already registered, do not send a new invitation link — instead, direct the client to go to your whitelabel domain and use the Sign In option (Avatar → Agency Settings → White Label Setup) rather than following any old invite link. 5. If the client was never fully registered, resend the invitation from the Agency Whitelabel settings page. Make sure the client opens the new email and ignores any previous invite links. 6. Ask the client to open the new invitation link in a private/incognito browser window to avoid any cached session conflicts. 7. Have the client complete the full registration flow without closing the browser tab or refreshing mid-process. 8. If the client encounters a reCAPTCHA screen that does not progress, ask them to try a different browser or disable any browser extensions that may be blocking scripts. 💡 Tips to Prevent This Error in Future - Always send a fresh invitation if you are unsure whether the previous one was completed — old links can cause broken flows. - Remind clients to use the login page on the whitelabel domain once they have registered, rather than re-clicking their original invite email. - Avoid sending multiple invitation emails in quick succession, as this can create conflicting links. - If a client is already registered and locked out, a password reset on the whitelabel login page is usually faster than re-inviting them. 🚀 Still Seeing the Error? If you have followed all the steps above and the whitelabel registration or invitation error persists, our team can investigate the specific account configuration on your behalf. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🔧 Fix White-Label Portal Access After Account Transfer

Overview When an account is transferred or a white-labeled domain is updated, existing user sessions and permissions can break. This article explains what is known about the Invitation Required screen and what to do if you or your team members lose access to your white-labeled portal after an account transfer. Why You May See an 'Invitation Required' Screen The Invitation Required screen can appear when a user attempts to access a white-labeled portal but does not have active access to that workspace. This may be related to changes made during an account transfer, such as domain updates or permission resets. The exact cause can vary depending on how the transfer was handled. Steps to Restore Access As the admin of the white-labeled portal, you can attempt the following self-serve steps to restore access for affected users: 1. Log in to your Search Atlas account as the current account owner or admin. 2. Navigate to your white-label settings by clicking the apps-grid icon in the header, then selecting More Features → Agency Hub (Set up your Agency's White Label). 3. Locate the affected user(s) under the team members or user management area of the portal settings. 4. Remove and re-invite the affected user(s): If a user's access appears broken or they are stuck on the Invitation Required screen, remove them from the portal and send a fresh invitation using their email address. Ask the user to check their spam or junk folder if the invitation email does not arrive in their inbox. 5. Confirm the correct domain is set: If the portal domain was updated as part of the account transfer, verify that the white-label domain in your settings matches the URL your users are attempting to access. A mismatch between the saved domain and the actual URL can trigger access errors. 6. Have the user accept the new invitation by clicking the link in the invitation email, then ask them to log in fresh rather than using a saved bookmark or cached session. What to Have Ready Before Contacting Support If the steps above do not resolve the issue, please have the following information ready when you reach out: - The name of the affected white-labeled portal or domain. - The email address(es) of any users who have lost access. - A description of when the issue started (e.g., immediately after the account transfer). - Any error messages you are seeing, including the exact text of the Invitation Required screen. - The name of the previous account holder, if the transfer was between different users. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🖼️ Fix White-Label Logo Disappearing After Save

📋 Issue Overview When you upload a custom sign-in logo in Agency Settings and click Save, the logo disappears after a page refresh. Your white-label reports then show the default branding instead of your agency logo. ✅ Root Cause and Fix This was a confirmed platform defect (Linear tickets WL-254 and SPE-783). The problem occurred because the single-page application navigation did not properly refetch your updated profile data after saving. Engineering has deployed the fix to production, so logo uploads now persist correctly. 🛠️ Steps to Upload Your Logo Successfully 1. Log in to Search Atlas and open Settings → Agency Settings → White Label Setup → Logo tab. 2. Locate the Upload Agency Logo field. 3. Click Choose File and select your logo image (recommended: PNG or SVG, max 2 MB, 300×100 px). 4. Click Continue at the bottom of the page. 5. Wait for the green confirmation toast, then refresh the page (F5 or Ctrl+R). Your logo should remain visible. ✅ Verify the Fix - Open an incognito window and visit your agency's sign-in URL. - Confirm the custom logo appears on the sign-in page. - Generate a test report to ensure white-label branding carries through. 💡 Still Having Trouble? If the logo still disappears after following these steps, clear your browser cache or try a different browser. If the issue persists, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🏷️ Agency White-Label Logo Upload Not Working

What This Article Covers Some users have found that the logo upload button in the Agency Hub white-label setup does not respond when clicked, or that brand color settings cannot be changed. Follow the troubleshooting steps below to resolve this on your own before reaching out to support. Troubleshooting Steps Work through these steps in order. Most users are able to resolve the issue before reaching the end of the list. 1. Try a different browser. If you are using Chrome on Windows, switch to Firefox or Edge. This issue has been reported specifically on Chrome for Windows and switching browsers has resolved it for many users. 2. Open an incognito or private window. Browser extensions can interfere with file picker dialogs. Open an incognito window (Chrome: Ctrl+Shift+N / Mac: Cmd+Shift+N), navigate to the Agency Hub white-label setup, and attempt the upload again. 3. Clear your browser cache and cookies. Go to your browser settings, clear cached images and files as well as cookies, then reload the page and try again. 4. Check your image file format and size. Use a PNG or JPG file under 2 MB. Files that are too large or in an unsupported format (e.g., WEBP, SVG, HEIC) may cause the button to appear unresponsive without showing an error. 5. Disable browser extensions temporarily. Ad blockers, privacy extensions, and script blockers can prevent the file picker from opening. Disable all extensions, reload the page, and retry the upload. 6. Refresh the page and try again. If a previous upload attempt timed out, a simple hard refresh (Ctrl+Shift+R / Cmd+Shift+R) can clear the stuck state. Still Not Working? If you have tried all of the steps above and the logo upload button is still unresponsive or your brand color settings are not saving, please reach out to our support team via the chat widget below and include the following details so we can investigate efficiently: - The browser and operating system you are using - A brief description of what happens when you click the upload button (for example, nothing happens, an error appears, or the page reloads) - Which troubleshooting steps you have already tried - The file format and size of the logo you are trying to upload You can also start a live chat with us by clicking the chat widget in the bottom-right corner of the platform and typing human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

Bug Reporting for Whitelabel Resellers: Complete Guide

Overview If you are a Search Atlas reseller, you access the platform through a custom whitelabel URL branded for your agency. While this panel is ideal for managing clients, bug reports and support tickets should be submitted through the standard Search Atlas domain. This article explains the correct workflow for reporting bugs as a reseller. Why Use the Standard Domain for Bug Reporting The whitelabel reseller panel is a customised environment designed for client-facing work. When submitting a bug report, use the standard Search Atlas domain rather than your whitelabel URL to ensure your reseller account is properly recognised by the support team. Which Domain to Use for Bug Reporting To submit a bug report, always use the standard Search Atlas domain rather than your whitelabel URL. Log in with your reseller account credentials to access the standard platform. How to Report a Bug as a Reseller 1. Go to the standard Search Atlas domain. Do not use your whitelabel URL for this process. 2. Log in with your reseller account credentials. 3. Reproduce or locate the bug. Navigate to the area of the platform where the issue occurs. 4. Gather the details needed to escalate effectively: note the exact URL of the page where the bug appears, the precise error message or unexpected behaviour you are seeing, the date and time the issue occurred, and the name of the affected project or client account if applicable. 5. Contact the support team while logged in through the standard Search Atlas domain with the details above ready so the team can investigate and resolve your report as quickly as possible. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🏷️ Fix White-Label Branding in Report Builder

🔍 Overview If your white-label portal is showing default Search Atlas or OTTO SEO labels instead of your custom branding — for example, displaying OTTO SEO instead of a renamed label like Harvey — this guide explains what to check and how to escalate if the issue persists. ⚙️ How White-Label Branding Works in Report Builder White-label settings control how your agency's branding appears across the platform, including reports generated in the Report Builder. Custom names, logos, and colors configured in your Agency Whitelabel settings should automatically reflect in any reports shared with clients. However, branding may not display correctly if the white-label configuration is incomplete or if the report was generated before your branding was fully configured. 🛠️ What to Check Because the exact steps to resolve this issue depend on your specific account configuration, our support team will need to investigate directly. Before reaching out, please have the following information ready: - Your project or report name where the branding is not displaying correctly. - The specific label or element that is showing the default name instead of your custom branding (for example, a feature name, logo, or agency name). - A screenshot showing the incorrect branding as it currently appears. - The date and time when you first noticed the issue. - Whether you have recently made any changes to your Agency Whitelabel settings. ✅ Quick Checklist Before Escalating - Confirm your white-label settings are fully filled in — check that your custom agency name, logo, and any renamed feature labels are entered in your Agency Whitelabel settings. - Re-save your settings — open your Agency Whitelabel configuration, review all fields, and save again to ensure no changes were lost. - Try regenerating the report — if possible, create a new report after confirming your settings are saved, as older reports may not automatically reflect updated branding. If none of the above resolves the issue, please contact our support team with the details listed above so we can investigate your account configuration 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.

Last updated on Oct 26, 2026

🔧 Fix AI Credits Not Working in Whitelabel Accounts

🧠 Why This Happens If your whitelabel client account shows AI credits but those credits cannot actually be used, the most common cause is a zero-quota configuration. This affects agency starter accounts — accounts created at no cost under your agency — because starter accounts are not automatically assigned a usable AI credit quota, even when the credit balance appears to be greater than zero. This is not a bug with your API keys or a Bring Your Own Keys setup issue. The credit display reflects what is available at the agency level, but the individual whitelabel account needs its own quota allocation before it can consume those credits. 🔍 How to Confirm This Is Your Issue - The whitelabel account shows a non-zero AI credit balance on its dashboard. - Attempting to use any AI-powered feature returns an error or silently fails. - The account was created as a starter (free) whitelabel seat under your agency plan. - The issue has occurred before, even after the client reported it resolved. ⚙️ How to Fix It There are two ways to resolve this depending on your agency setup and your client's needs. Option 1: Assign a Quota from Agency Settings 1. Log in to your Search Atlas account as the agency owner or admin. 2. Click your avatar in the top-right corner to open the Avatar Menu (👤). 3. Navigate to Settings (URL: /settings). 4. Select the Team Members section. 5. Locate the whitelabel account in question — in this example, Castelo Portraits. 6. Open the account settings for that user and locate the AI credit quota setting for that account. 7. Enter a specific quota amount to allocate from your agency's total credit pool. 8. Save your changes. Once a quota is assigned, the whitelabel account will be able to use AI features immediately without any further changes on the client's side. Option 2: Upgrade the Account to a Paid Plan If your client needs consistent, independent access to AI credits, the most reliable long-term solution is to assign them a paid plan. Paid whitelabel accounts receive their own quota allocation automatically and do not depend on manual quota resets from agency settings. Contact your account manager via the chat widget to discuss plan options for your whitelabel seats. 🔁 Why This Issue Can Recur If you have resolved this before and it has happened again, the likely explanation is one of the following: - Quota was not saved correctly during the previous fix — always confirm the quota field shows a number greater than zero after saving. - Quota was reset during a billing cycle refresh at the agency level, returning the starter account to zero. - A new starter account was created for the same client without carrying over the quota setting. To prevent recurrence, we recommend either assigning a quota as part of your standard whitelabel account setup checklist, or moving recurring clients to a paid plan. 🚫 What Will Not Fix This Issue The following steps are not related to this problem and will not resolve it: - Adding or removing API keys under Bring Your Own Keys settings. - Reconnecting third-party AI provider credentials. - Asking the client to clear their browser cache or log out and back in. - Refreshing the credit balance display on the dashboard. If you have already tried these steps following previous support guidance, please disregard them and follow the quota assignment steps in this article instead. 💬 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.

Last updated on Oct 26, 2026

⚡ White-Label Client Accounts and Rank Tracker Errors

Overview This article covers two related topics: how to create a white-label client account that includes integrations, and what to do if you encounter a 400 error in Rank Tracker that prevents keywords from being added to a project. Setting Up a White-Label Client Account with Integrations White-label client accounts allow your customers to access Search Atlas tools under your agency's branding. When setting up a client account, you can configure it so that the relevant integrations are connected and the client's dashboard reflects the correct data for their domain. If you need help connecting specific integrations to a white-label client account or are unsure which integrations are available for sub-accounts, please reach out to support with the following information ready: - Your agency account name - The client account name or domain - Which integrations you are trying to connect - Any error messages encountered during setup Rank Tracker 400 Error When Adding Keywords Some users encounter a 400 error in Rank Tracker that prevents keywords from being added to a project. This is a known bug that requires investigation on the backend to identify what is causing the request to fail for the specific project and account. If you are experiencing this error, this cannot be resolved through account settings alone. To escalate effectively, please have the following ready when you contact support: - The exact error message displayed (screenshot if possible) - The name of the Rank Tracker project affected - The domain associated with the project - The keywords you were attempting to add when the error occurred - The approximate date and time the error first 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.

Last updated on Oct 26, 2026

🛠️ Fix Zero-Quota AI Credits on Agency Starter Accounts

🔍 Overview Some agency whitelabel accounts display a full AI credit balance yet are unable to use those credits. This issue is most common on Agency Starter plans and can affect any client account managed under your whitelabel workspace. This article explains why it happens and walks you through the steps to resolve it. 💡 Why This Happens The AI credit display on a whitelabel account reflects the allocated quota — the amount you have assigned to that account. However, if the underlying quota configuration is not correctly synced between the parent agency account and the client sub-account, the credits appear available but are blocked at the usage level. Common triggers include: - The Agency Starter plan's AI credit pool was reset or adjusted without re-syncing allocations to client accounts. - A previous billing cycle change left the sub-account quota in a zero or locked state despite the dashboard showing credits. - The whitelabel account was created or modified while a plan upgrade or renewal was processing. ⚙️ How to Check Your AI Credit Allocation 1. Click your avatar in the top-right corner of the platform to open the Avatar Menu (👤). 2. Select Team Members or navigate directly to /settings. 3. Locate the affected whitelabel account (e.g., Castelo Portraits) in your client account list. 4. Review the AI credit allocation shown for that account. Confirm that a non-zero value is saved and active — not just displayed. 🛠️ Steps to Resolve the Issue 1. Re-save the credit allocation: Open the whitelabel account settings, clear the current AI credit value, re-enter the desired amount, and click Save. This forces a fresh sync between the parent account and the sub-account. 2. Verify the parent account balance: Ensure your main Agency Starter account has sufficient AI credits available to cover the allocation. If the parent pool is at zero, replenish it before re-allocating. 3. Log out and log back in: After saving, ask the affected client (or switch to their account) to log out and log back in. This clears any cached quota state on their session. 4. Test a small AI task: Once back in the account, attempt a low-cost AI action (such as generating a short content brief) to confirm credits are now active and deducting correctly. 🔄 Preventing This Issue in the Future - After every plan renewal or upgrade on your agency account, revisit your client credit allocations and re-save them to ensure they remain in sync. - Avoid modifying credit allocations during active billing transitions — wait until a new cycle is fully confirmed. - Periodically audit your whitelabel accounts under /settings to confirm allocations reflect intended values. 🆘 Still Experiencing the Issue? If you have followed all the steps above and the affected account still cannot use AI credits, our team can investigate the quota sync at the account level. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🔧 Fix Whitelabel Custom Domain DNS

🔍 Why your whitelabel domain stopped working A whitelabel domain, such as seodashboard.webeagles.com.au, uses a DNS CNAME record to point to Search Atlas. Changing your website server does not usually update this record, but DNS settings may have been removed, replaced, or changed during the migration. The domain can also stop working when the CNAME points to an outdated destination, uses the wrong record type, or conflicts with another DNS record. ⚙️ Check the required DNS record 1. Open the whitelabel or custom-domain settings in Search Atlas. 2. Copy the current CNAME target shown in the platform. 3. Open your domain provider’s DNS management page. 4. Find the hostname used for your whitelabel domain, such as seodashboard. 5. Set its record type to CNAME. 6. Enter the exact target copied from Search Atlas. 7. Save the DNS change. Use a CNAME record, not an A record or an IP address. Do not add https:// to the target. If your DNS provider automatically adds the main domain, enter only the hostname required by that provider. 🛠️ Remove common DNS conflicts - Remove any existing A, AAAA, or conflicting CNAME record for the same hostname. - Make sure the CNAME is created for the subdomain, not the root domain, unless the platform specifically instructs otherwise. - Check that the hostname is spelled correctly and does not contain duplicate domain text. - If a proxy or CDN is enabled, temporarily disable proxying or set the record to DNS-only while the domain is verified. ⏳ Wait for DNS updates DNS changes can take time to appear across the internet. Wait several minutes, then retry verification in Search Atlas. In some cases, cached DNS records can take up to 24–48 hours to expire. ✅ If your website recently moved servers Your website’s A record and your Search Atlas whitelabel CNAME serve different purposes. Update the website records required by your new hosting provider, but keep the whitelabel subdomain’s CNAME pointing to the exact destination shown in Search Atlas. If the domain still fails after the CNAME is correct and DNS has updated, confirm that the domain is entered correctly in Search Atlas and that your hosting or security provider is not blocking the request. 💬 Get help with verification If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🏷️ Set Up White Label DNS Configuration Correctly

🌐 Overview White label setup lets you serve Search Atlas reports and tools under your own custom domain. To make this work, your domain must point to Search Atlas using a CNAME record. Using an incorrect record type — such as an A record — will cause the setup form to fail and your white label domain to not function properly. ⚠️ Important: Use a CNAME Record, Not an A Record A previous version of our guidance incorrectly instructed customers to create an A record pointing to the IP address 35.243.150.225. This is outdated and incorrect. Do not use that IP address or an A record for white label DNS setup. The correct configuration requires a CNAME record targeting: - Record type: CNAME - Host / Name: your chosen subdomain (for example, reports or seo) - **Value / Target:**whitelabel.dns.searchatlas.com - TTL: 3600 (or your DNS provider's default) Using an A record instead of a CNAME record will prevent the platform from verifying your domain and will cause form submission errors during white label setup. 🛠️ Step-by-Step DNS Setup 1. Log in to your domain registrar or DNS provider (for example, Cloudflare, GoDaddy, Namecheap, or Route 53). 2. Navigate to the DNS settings or DNS management section for your domain. 3. Delete or remove any existing A record pointing to 35.243.150.225 if you previously followed the outdated instructions. 4. Create a new DNS record with the following values: - Type: CNAME - Host / Name: enter your chosen subdomain, for example reports (this will create reports.yourdomain.com) - **Value / Target / Points to:**whitelabel.dns.searchatlas.com - TTL: 3600 or Auto 5. Save the record and allow up to 24–48 hours for DNS propagation, though changes often take effect within 1–2 hours. ✅ Complete the White Label Setup Form 1. In Search Atlas, go to More Features → Agency Hub (Agency Settings). 2. Navigate to your white label settings and open the setup form. 3. Enter your full custom subdomain, for example reports.yourdomain.com. 4. Submit the form. The platform will attempt to verify your CNAME record. 5. If verification succeeds, your white label domain will be activated. If you see a form submission error, check the troubleshooting steps below before retrying. 🔍 Troubleshooting Form Submission Errors If you still see a form submission error after updating your DNS record, work through the following checks: - Confirm you deleted the old A record. Having both an A record and a CNAME record for the same subdomain will cause a conflict. Most DNS providers will not allow this, but verify there are no conflicting records. - Check propagation status. Use a free tool such as whatsmydns.net and search for your subdomain as a CNAME. It should return whitelabel.dns.searchatlas.com. If it still shows an IP address, propagation is not yet complete — wait and try again. - Verify the subdomain matches exactly. The subdomain you enter in the Search Atlas form must match the host value in your DNS record exactly, including capitalisation. - Check for a proxy or CDN override. If you use Cloudflare, make sure the CNAME record is set to DNS only (grey cloud icon) rather than Proxied (orange cloud) during initial setup and verification. - Confirm there are no typos in the target. The CNAME target must be exactly whitelabel.dns.searchatlas.com with no extra characters or spaces. 📋 Quick Reference: Correct DNS Record - Record type: CNAME - Host / Name: your subdomain (example: reports) - **Target / Value:**whitelabel.dns.searchatlas.com - TTL: 3600 or Auto - Do NOT use: A record or the IP 35.243.150.225 💬 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.

Last updated on Oct 26, 2026

🔧 White Label Preview Pricing and Dashboard Fix

A bug affecting white label preview sessions has been resolved as of the 2026-07-21 release (WL-316). If you are still seeing unexpected content in your white label preview, use the steps below to confirm the fix is in place and to escalate if the issue persists. ✨ What Was Fixed A bug caused unintended content to be visible during white label preview sessions. This has been addressed in the latest release. If you set up your white label preview before this release date, the fix should now be applied to your account automatically. 🛠️ Steps to Confirm the Fix 1. Navigate to the Header apps-grid icon → More Features → Agency Hub (Set up your Agency's White Label). 2. Open or share a preview of your white label environment. 3. Check whether the preview now displays only the branding and content intended for your clients. 4. If you are still seeing unexpected elements in the preview, take note of: your account or project name, a description of exactly which elements are still visible, and the date and time you observed the issue. 📋 Still Experiencing the Issue? If the white label preview is still showing content it should not after following the steps above, please reach out to our team with the following information ready so we can investigate quickly: - Your account or project name - A description of the specific elements still visible in the preview (e.g., which content or sections appear unexpectedly) - The date and time you first noticed the problem - Any screenshots if possible If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Last updated on Oct 26, 2026

🔗 Fix White-Label Links in AI Visibility Report Emails

🔍 Overview If you are using Search Atlas under a white-label setup, you may notice that automated AI Visibility report emails contain links pointing to the default Search Atlas domain rather than your custom white-label domain. This article explains why this happens and what steps you can take right now. ⚙️ Why This Happens Automated AI Visibility report emails are generated by a background process that builds report links automatically on a schedule. Currently, this process does not yet read your white-label domain setting when constructing those links. As a result, any clickable link inside the emailed report routes recipients to the default Search Atlas domain instead of your branded URL. This is a known platform issue. Our engineering team has identified the root cause — the automated report mailer needs to use your configured dashboard base URL — and a fix is actively in progress. No action on your end caused this behaviour. 🚨 Who Is Affected - Agencies and resellers who have configured a custom white-label domain inside Search Atlas. - Any client or team member who receives automated scheduled AI Visibility report emails and clicks a link inside them. - White-label setups where maintaining brand consistency in client communications is critical. If you are not using a white-label domain, your report links will work as expected and this issue does not apply to you. ✅ What You Can Do Right Now While the platform fix is being released, use the steps below to share correctly branded reports with your clients. 1. Log in to your Search Atlas white-label dashboard using your custom domain. 2. In the left sidebar, click Reports to open the Report Builder (you can also navigate directly to /report-builder/projects-list). 3. Locate the AI Visibility report you want to share. 4. Open the report and copy the URL from your browser address bar. Because you are already logged in through your white-label domain, this link will reflect your branded URL. 5. Share this copied link with your client directly — via email, messaging, or your preferred channel. This manual method ensures every link you send carries your white-label domain until the automated emails are updated. 📋 Additional Tips - Pause scheduled email delivery (if possible): If sending unbranded links to clients would cause confusion or brand concerns, consider temporarily pausing any automated AI Visibility email schedules until the fix is live. - Set expectations with clients: If a client has already received an email with a Search Atlas domain link, let them know it is a temporary technical issue and provide them with the correct white-label link using the steps above. - Bookmark your white-label Reports page: Keeping /report-builder/projects-list bookmarked under your custom domain makes it faster to grab correctly branded links on demand. 🛠️ Platform Fix Status Our engineering team has confirmed this issue and a fix is currently in release. Once deployed, the automated report mailer will use your white-label domain when generating all links inside scheduled AI Visibility emails. No configuration change will be required on your end — the fix will apply automatically to your account. We recommend checking platform release notes or announcements for confirmation once the update is live. 💬 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.

Last updated on Oct 26, 2026

🛠️ White Label Audit Widget Registration

🔍 What the registration prompt means The White Label Site Analysis lead-capture widget is designed for public visitors to submit their details without signing in. If visitors see an Invitation required message or are prompted to register, the widget may be using an outdated version or an old session state. ✅ Confirm the widget type - Site Analysis widget: This is the White Label audit widget for collecting leads from website audits. - GBP Local Audit widget: This is the newer widget for local business profile audits. It is configured separately from the Site Analysis widget. Make sure you are testing the widget intended for your campaign and that its embed code matches the widget configured in your Search Atlas account. 🧪 Test the widget as a visitor 1. Open the published page containing the widget in a private or incognito browser window. 2. Test it while signed out of Search Atlas. 3. Enter a valid website or business profile, depending on the widget type. 4. Confirm that the form accepts the submission without requesting an invitation or platform registration. Testing in a normal browser session can show different results because you may already be authenticated. 🔄 Refresh the installation 1. Remove the existing widget code from the page. 2. Copy the current embed code from your White Label settings. 3. Paste the code back into the page and publish the changes. 4. Clear your site or CDN cache, if applicable. 5. Repeat the test in a private browser window. If your site uses a page builder, confirm that it has not altered or blocked the script during publishing. 📊 Check the related settings Review your White Label configuration and confirm that the widget is enabled and connected to the correct agency or project. For Site Analysis reporting, you can review related projects from Reports in the left sidebar. For GBP Local Audit activity, open Local in the left sidebar and review the relevant project. 🚀 If the prompt continues The Site Analysis widget had a known issue that could show an invitation requirement to unauthenticated visitors. That issue has been resolved. If the prompt still appears after refreshing the embed code, clearing caches, and testing while signed out, record the page URL, widget type, browser, and exact message shown. 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.

Last updated on Oct 26, 2026

🛠️ Test Your Lead Capture Widget

🔍 Why the invitation error appears If you see “Registration on this domain is by invitation only. Please contact your account administrator to receive an invitation.”, the widget is working as intended. The domain is configured to allow registrations only from invited users. This usually means the test visitor is not signed in with an approved invitation, or the domain has not been configured for open registration. ⚙️ Open the widget settings 1. Sign in to your Search Atlas account. 2. Open More Features → Agency Whitelabel. 3. Select Site Analysis Lead Capture Widget. 4. Review the widget setup, registration, and domain settings. 🧪 Test the widget 1. Open the published page containing the widget in a private or incognito browser window. 2. Enter test details that are not already registered, unless you are testing an existing user flow. 3. Submit the form and confirm that the expected registration or lead capture message appears. 4. Check that the captured lead appears in the appropriate area of your platform. 👤 Test an invitation-only setup For domains restricted to invited users, ask the account administrator to send an invitation to the email address used for testing. Open the invitation and complete registration before submitting the widget again. If you manage the account, review the registration settings under More Features → Agency Whitelabel → Settings. Use the option that matches your intended access policy, then save the change and repeat the test. 🛠️ Troubleshoot failed tests - Confirm that the widget is installed on the correct white-labeled domain. - Check that the domain and page use the latest saved widget configuration. - Test in a private window to avoid cached sessions or previously stored cookies. - Verify that the test email has received and accepted an invitation when registration is restricted. - Make sure required form fields are completed and the submission is not blocked by a browser extension. 💬 Get help If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.

Last updated on Oct 26, 2026

🌐 How to Complete White Label Domain Setup

🔎 What Is White Label Domain Setup? White labeling lets you show your clients the platform on your own domain (for example, reports.youragency.com) instead of the default Search Atlas address. Setup has two parts: adding your domain in Agency Settings, and adding the matching DNS records at the company that manages your domain (your DNS provider). Most setup problems happen in the second part. A missing, outdated, or conflicting DNS record can stop the domain from connecting or make it unreachable. ✅ Before You Start - Make sure you can log in to your DNS provider. This is usually your domain registrar, hosting company, or a service like Cloudflare. - Choose a subdomain such as app.youragency.com or reports.youragency.com. Using a subdomain is the safest option because your main website stays untouched. - Do not use the same address your public website runs on. Pointing that address to the platform will replace your website and can cause access problems. - Keep the exact DNS record details shown in your white label settings open. Always copy the values from there rather than from older notes or other articles. 🛠️ Step-by-Step: Connect Your Domain 1. Log in to Search Atlas and open Agency Settings. 2. Go to the White Label section and enter your chosen domain or subdomain. 3. Save your entry. The platform will display the DNS records you need to add, including the record type, name (host), and value (target). 4. Log in to your DNS provider and open the DNS management page for your domain. 5. Add each record exactly as shown. Copy and paste the values to avoid typos, and check that your provider has not added your domain name twice in the host field. 6. Remove any older record for the same subdomain that points somewhere else. Two conflicting records for one name can prevent the domain from working. 7. Save your changes and return to Agency Settings to run the verification check. 8. If verification does not pass right away, wait and try again. DNS changes can take anywhere from a few minutes to 24-48 hours to take effect. 🚧 Locked Out After Pointing the Domain Directly? If you pointed your domain straight to the platform and can no longer reach it, you can recover access in a few steps. 1. Log in using your standard Search Atlas login page rather than your custom domain. Your account itself is not affected by DNS changes. 2. Open Agency Settings and review the white label records shown for your domain. 3. In your DNS provider, compare those records with what is currently set. Look for records that point the whole domain to the wrong place, or that do not match the values in your settings. 4. If you are using the main domain (such as youragency.com), switch to a subdomain instead and update the domain in your white label settings. 5. Restore any records your website or email needs, so those services keep working. 6. Save your changes and allow time for DNS to update. 🖥️ Moved Servers? Check for Missing DNS Records When you move to a new server or hosting company, DNS records often do not move with you. This is the most common reason a white label domain stops working after a migration. Check the following: - Where your DNS is managed: Your nameservers decide which DNS panel is active. If you changed nameservers during the move, records added at your old host no longer apply. Add the white label records in the DNS panel that is currently active. - Missing records: Compare the records in your DNS panel with the ones listed in your white label settings. Add any that are missing, including verification records. - Old or conflicting records: Delete any leftover records for the same subdomain that still point to your previous server. Stale IPv4 or IPv6 address records are a common cause. - Proxy or CDN settings: If you use a service such as Cloudflare, set the record to DNS only (proxy off) while verifying the domain. - Typos or extra characters: Make sure there are no extra spaces, missing dots, or duplicated domain names in the record values. ⏱️ Allow Time for DNS to Update DNS changes are not always instant. Here is what to expect: - Most changes appear within 15-60 minutes. - Some take up to 24-48 hours, depending on your provider. - If you recently deleted or edited a record, your device or network may still show the old result for a while. Try a private browser window or a different network. 🧰 Quick Troubleshooting Checklist - Verification fails: Check that the record type, name, and value match your settings exactly, then wait and retry. - Site shows an error or a security warning: The domain may still be updating. Wait a few hours, then refresh. Make sure no conflicting records exist. - Your website went offline: You may have pointed your main domain to the platform. Restore your original website records and use a subdomain for white labeling. - Domain worked before the move but not now: Re-add the records in your new DNS panel and remove old ones. - Still not loading: Confirm the domain is saved in Agency Settings and that you are testing the exact domain you entered. 💬 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. To help us resolve your issue faster, please have these details ready: the domain you are trying to connect, the DNS provider you use, and the records currently set for that domain.

Last updated on Oct 26, 2026