Troubleshooting: Instant Indexing Issues

🛠️ GSC & Bing Indexing, AI Credits, and Domain Knowledge Network (DKN) Troubleshooting

Fix GSC Instant Indexing failures, meet Bing Indexing requirements, recover missing AI Premium credits, and use the Domain Knowledge Network (DKN) to close content gaps and grow your site's topical authority. 📡 GSC Instant Indexing Is Not Working GSC Instant Indexing connects Search Atlas to Google Search Console so you can request faster crawling and indexing of your pages. There are two distinct failure modes — identify which one applies to you before taking action. 1. Connection or authentication issues (re-authenticate via OAuth) Use this flow when Search Atlas shows your Google Search Console integration as disconnected, errored, or with an expired token. 1. Go to Settings → Integrations in Search Atlas. If you don't see Integrations, contact Support to confirm your plan includes GSC Instant Indexing. 2. Confirm your Google Search Console property shows a Connected status. 3. If the status shows an error or expired token, click Reconnect and complete the Google OAuth flow. Known display bug: If the GSC Performance report shows an Authorize Connection screen only when you change the time-range filter (for example, switching from 1 Year to 1 Month or 2 Months), this was a previously documented display bug that is now resolved. Refresh the page first; if the screen persists, clear your browser cache before attempting to reconnect. 2. Connection is valid but indexing requests still fail Use this flow when your GSC integration shows as Connected but URL submissions are not being processed, or when the Generate Unique Address button returns an error. - Generate Unique Address button returns an error: Clear your browser cookies and cache, reload the page, and retry. If the error persists, contact Search Atlas Support — an agent can retrieve your service-account address directly from the backend (example format: indexing-[customer]@indexed-[hash].iam.gserviceaccount.com). - Submissions appear accepted but pages are not being indexed: Check status.searchatlas.com for any active incidents before contacting Support. If an active incident is listed, no further action is needed — the team is already investigating. Subscribe to incident updates on that page, or open a support ticket to be notified when the issue is resolved. 🔗 Bing Indexing Requires Root Domain Access Bing Indexing uses the Bing URL Submission API. This API requires root domain ownership verified in Bing Webmaster Tools — subdomain or subfolder-level access is not sufficient and will prevent submissions from being accepted. Requirements before connecting Bing Indexing - Root domain verification: Verify ownership of the root domain (e.g., example.com) in Bing Webmaster Tools — not a subdomain (blog.example.com). - Bing Webmaster Tools API key: Generate an API key under Settings → API Access in Bing Webmaster Tools. How to connect Bing Indexing in Search Atlas 1. Complete root domain verification in Bing Webmaster Tools. 2. Copy your API key from Bing Webmaster Tools. 3. In Search Atlas, go to Settings → Integrations → Bing Indexing and paste the API key. 4. Save and re-submit your URLs for indexing. Once root-level access is confirmed and the API key is saved, Bing Indexing will show accepted submissions in the integration dashboard. ✍️ Error When Editing the "About the Author" Section If you see an error while editing an article's About the Author section, this is a known intermittent issue caused by the Content AI processing pipeline. No article data is lost when this error occurs. What to do - Wait a few minutes, reload the tab, and try the edit again. - Check status.searchatlas.com to see if a Content AI incident is currently active. - If the error persists for more than 30 minutes, contact Search Atlas Support with your article URL and the full error message so the team can investigate. The Search Atlas team actively monitors and mitigates this issue. Once the pipeline clears, the edit will complete normally. 💳 Missing AI Premium Credits — How Quotas Work and How to Restore Them AI Premium credits come in two distinct types. Understanding the difference is essential when credits appear missing or cannot be restored. Recurring vs. non-recurring credits - Recurring credits reset automatically each billing cycle. If these appear missing or incorrect, Support can restore them directly. - Non-recurring credits are one-time top-ups. Once consumed, they cannot be restored — Support cannot reissue spent non-recurring credits. Steps if your AI Premium credits are missing 1. Contact Search Atlas Support and specify whether the missing credits were recurring or non-recurring. 2. After Support restores your recurring credits, reload the tab — the updated balance appears immediately on refresh. 3. Verify your credit balance under the account menu (person icon, top-right) → Billing → Plans & Top-ups. 4. If non-recurring credits were consumed unexpectedly, provide Support with the date and the feature where they were used so the team can review the usage logs. After a Support-initiated restore, your recurring credit balance will reflect the correction on the next page reload. 🗺️ Domain Knowledge Network (DKN) — Best Practices for Content Strategy The Domain Knowledge Network (DKN) maps the topical coverage of your domain and surfaces gaps where content is missing. Use it to make deliberate, cluster-driven editorial decisions rather than publishing on disconnected topics. How to read the DKN map - Gaps on the map are topics your domain has not yet covered — each gap is a candidate for your next article. - Incomplete clusters — topic groups where you have 1–2 articles but not full coverage — signal the highest-priority opportunities. A few targeted articles can close the cluster and send stronger topical authority signals to Google. DKN prioritization strategy 1. Start with incomplete clusters. Expanding a cluster you've already started is more efficient than opening a new one from scratch. 2. Prioritize by authority potential. Focus on clusters in your core niche before moving to adjacent topics. 3. Follow the clusters, not random topics. Use the DKN as your editorial calendar — each article should advance a specific cluster toward completion. 4. Pair DKN with the Search Atlas Content Planner. Once you identify which cluster gaps to fill, use the Content Planner to brief and create those articles. DKN resources - Review the DKN documentation for a full feature walkthrough. - Watch the Search Atlas DKN training sessions for guided walkthroughs using real-world examples. When used consistently, the DKN shortens the path to topical authority by showing you exactly which articles to write next — and in what order. 🎯 You now know how to verify and fix GSC and Bing Indexing connections, recover missing AI Premium credits, work around the intermittent Content AI editing error, and use the Domain Knowledge Network to build a cluster-driven content strategy. For real-time platform status on any issue, always check status.searchatlas.com first.

🔍 Fix Pages Flipping Between Indexable and Not-Indexable

🧭 What This Article Covers If you notice a page alternating between Indexable and Not-Indexable status in Search Atlas, this guide walks you through the most common causes and the steps to resolve them permanently. ⚠️ Why Indexability Status Keeps Changing Indexability flipping is almost always caused by one or more conflicting signals on the page or server. Google re-crawls pages on its own schedule, and each crawl can return a different result if the underlying signals are inconsistent. Common root causes include: - Conflicting noindex directives — a noindex meta tag exists in some page states (e.g. logged-in vs. logged-out, A/B test variant, or CMS draft mode) but not others. - Inconsistent canonical tags — the canonical URL changes between crawls, making Google treat the page as alternately authoritative or duplicate. - robots.txt blocking and unblocking — deployment pipelines or CDN rules that toggle robots.txt entries across environments (staging vs. production). - Conditional server responses — the server returns a 200 for some user agents and a 403/404/503 for Googlebot, depending on caching or bot-detection rules. - JavaScript rendering delays — a client-side script injects a noindex tag after the initial HTML loads, so the directive appears only when JS renders fully. - CMS workflow settings — publishing, scheduling, or preview modes that temporarily alter meta robots values. 🛠️ Step-by-Step Troubleshooting 1. Audit the page in Search Atlas On-Page Audit. Navigate to Left sidebar → Content → On-Page Audit, enter the affected URL, and check the Indexability section. Note every flag raised — pay particular attention to meta robots, canonical, and HTTP status warnings. 2. Inspect the live page source. Open the URL in a browser, right-click, and select View Page Source. Search for noindex, nofollow, and canonical. Then repeat the check using a tool that renders JavaScript (such as Google Search Console's URL Inspection → Test Live URL) to see the rendered DOM. Compare both versions. 3. Check your robots.txt. Visit yourdomain.com/robots.txt and confirm the affected URL or its directory is not disallowed. If you use separate staging and production environments, verify the correct robots.txt is being served in production. 4. Review server response codes. Use Google Search Console's URL Inspection tool to see the HTTP response Googlebot receives. If it differs from what a browser sees, investigate your CDN, WAF, or bot-detection configuration. 5. Check for A/B testing or personalisation scripts. If you run split tests or personalised content, ensure the control variant — and every variant — does not conditionally inject a noindex tag. Use the Fetch as Google option in URL Inspection to confirm what Google actually sees. 6. Audit your CMS publishing workflow. In WordPress, Shopify, or similar platforms, check that draft, scheduled, or preview states cannot be accessed by Googlebot. Restrict preview URLs with a password or IP allowlist rather than a noindex tag on the live URL. 7. Stabilise the canonical tag. Ensure the canonical tag on the page always points to the same, final URL — including consistent use of www vs. non-www, HTTP vs. HTTPS, and trailing slashes. 8. Re-run On-Page Audit after each fix. Return to Left sidebar → Content → On-Page Audit and re-audit the URL to confirm all indexability flags are resolved before requesting re-indexing. ✅ Confirming the Fix Once you have resolved the conflicting signals, take these final steps to accelerate stabilisation: - Submit the URL for re-indexing via Google Search Console → URL Inspection → Request Indexing. - Monitor the page's indexability status in Search Atlas over the following 7–14 days to confirm it stays consistently Indexable. - If you made changes to robots.txt, re-submit your sitemap in Google Search Console so Googlebot picks up the updated rules promptly. 💡 Prevention Tips - Use a staging subdomain with HTTP authentication rather than a noindex tag to protect pre-production pages. - Add indexability checks to your pre-deployment QA checklist so meta robots and canonical tags are verified before every release. - Schedule regular On-Page Audits in Search Atlas to catch any regressions early. 🙋 Still Need Help? If you have followed all the steps above and the page indexability is still flipping, our team is ready to investigate with 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.

🔍 Fix Search Atlas Sitemap Crawling and Page Indexing

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

🔧 Fix Duplicate OTTO JavaScript and GSC Instant Indexing

Overview Two issues can appear together on WordPress sites using OTTO SEO: a duplicate JavaScript warning caused by multiple OTTO pixel installations, and a Google Search Console (GSC) instant indexing connection failure. This guide walks you through the general approach to resolving both — removing the duplicate first, then reconfiguring the Search Atlas plugin with your UUID. Step 1: Identify All OTTO JavaScript Installations The duplicate warning appears when the OTTO pixel is loaded more than once on the same page. Before making any changes, check every location where the script could be installed: - Theme files: In your WordPress admin, look inside your theme's header and footer files for any snippet containing otto or your OTTO UUID string. - Code Snippets or similar plugins: Check any active snippet that references OTTO or inserts a tracking script. - Other plugins: Check any header/footer injection plugins for OTTO script fragments. Make a note of every location where the script appears before you remove anything. Step 2: Remove All Duplicate OTTO Scripts Remove the OTTO script from every location you found except the official Search Atlas WordPress plugin — that will be your single, authoritative source after reconfiguration. 1. Delete or disable the OTTO snippet in any code snippets plugin you are using. 2. Remove any OTTO script lines from your theme's header and footer files, then save each file. 3. Disable any other header/footer injection plugins that were loading the script. Step 3: Reconfigure the Search Atlas WordPress Plugin with Your UUID Once duplicate scripts have been removed, reconfigure the Search Atlas WordPress plugin using your OTTO UUID. Your UUID is available within your Search Atlas account. Enter it into the Search Atlas plugin on your WordPress site to reconnect the plugin as the single authoritative source of the OTTO pixel on your site. If you are unsure where to locate your UUID or which field to use in the plugin, contact our support team for guided assistance — they can walk you through the exact steps for your account. Step 4: Reconnect Google Search Console Instant Indexing After the plugin is properly configured with your UUID, reconnect your GSC instant indexing integration through the Search Atlas platform. If you encounter any difficulty completing this step, our support team can assist you 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.

💳 Billing, Indexing Plans, and Fixing Index Failures

📋 How Search Atlas Billing Works Your base subscription covers a fixed monthly allowance of indexing credits based on your plan tier. If you submit more URLs than your plan includes, Search Atlas may apply additional charges on top of your base plan fee to fulfil those requests. This means your monthly invoice may be higher than your base plan cost if you have submitted URLs beyond your included allowance. You can review all charges, credit usage, and top-up history at any time by clicking your Avatar (top-right) → Billing (Activity Log / Invoices tabs). - Base plan fee: charged on your renewal date regardless of usage. - Additional charges: may apply when your submitted URLs exceed your plan's monthly credit limit. - Credit rollover: check your plan details in your account settings to confirm whether unused credits carry over to the next billing cycle. 🔍 How Indexing Works in Search Atlas Search Atlas uses two indexing channels to submit your URLs to search engines: 1. Google Search Console (GSC) API — Search Atlas connects to your verified GSC property and submits URLs through Google's official indexing pipeline. 2. Bing IndexNow — URLs are simultaneously pinged to Bing and other IndexNow-compatible engines for faster discovery. Both channels must be correctly configured for indexing to work. If either connection is missing or broken, submissions may fail or return errors. ⚙️ Setting Up GSC and Bing IndexNow Google Search Console setup: 1. Navigate to the Integrations section inside your Search Atlas account settings and locate the Google Search Console option. 2. Initiate the connection and sign in with the Google account that owns your GSC property. 3. Select the correct property, making sure it matches the exact URL prefix or domain of your site. 4. Save the connection and confirm that the integration shows an active status before submitting URLs. Bing IndexNow setup: 1. Navigate to the Integrations section inside your Search Atlas account settings and locate the Bing IndexNow option. 2. Search Atlas generates a unique API key for your site — copy it as directed on screen. 3. Upload the key file to the root of your website as instructed (e.g., yoursite.com/your-key.txt). 4. Complete the verification step on screen. Once the integration shows an active status, Bing IndexNow is ready to use. If either integration shows a warning or disconnected status, re-authenticate or re-upload the key file before submitting URLs. 🚨 Why Your Pages May Not Be Indexing After Several Days Submitting URLs in Search Atlas does not guarantee immediate or complete indexing — search engines make the final decision. However, if a significant number of your submitted URLs remain unindexed after several days, work through the following checks: - Verify both integrations are active: Return to the Integrations section and confirm that both GSC and Bing IndexNow show an active (not disconnected or warning) status. A broken connection means submissions are not reaching search engines. - Check that the correct GSC property is selected: If the property in Search Atlas does not exactly match your site's URL (including http vs https and www vs non-www), submissions will fail silently. - Confirm the Bing IndexNow key file is accessible: Open a browser and visit yoursite.com/your-key.txt — if the file returns a 404 or is blocked, re-upload it to the root of your site. - Review your credit balance: If your plan's monthly indexing credit limit has been reached and no top-up has been applied, new URL submissions will not be processed. Check your credit usage under your Avatar (top-right) → Billing (Activity Log / Invoices tabs). - Check for crawlability issues: Search Atlas can submit URLs, but if those pages are blocked by robots.txt, require login, or have a noindex tag, Google and Bing will not index them regardless of submission. Review your pages directly to rule this out. - Allow additional time for lower-authority sites: New or low-authority domains may take longer for search engines to crawl and index even after a valid submission. This is normal search engine behavior and not a Search Atlas error. If you have confirmed all integrations are active, credits are available, and pages are crawlable, but indexing is still not occurring, escalate by opening the chat widget and providing your project name, the specific URLs affected, any error messages shown in the platform, and the date you first submitted those URLs. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Instant Indexing Token Generation Errors

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

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

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

🔍 Fix URL Indexer Quota After Hyperdrive Top-Up

🧭 Overview Some customers notice that their URL Indexer quota still displays as exhausted immediately after completing a Hyperdrive Credit (HDC) top-up. This can be alarming — especially if you have a large batch of URLs, such as newly purchased backlinks, waiting to be indexed. This article explains why this happens, what has been fixed, and what steps to take if you are still affected. ⚠️ What Caused This Issue A resolved platform bug affected how Hyperdrive Credits were converted into URL Indexer quota. Specifically: - In some cases, a top-up deducted Hyperdrive Credits from your balance but did not correctly award the corresponding URL Indexer quota. - In other cases, the quota display did not refresh after a successful top-up, making it appear as though no quota had been added even when it had. - A separate related issue caused top-ups to over-award quota or bypass credit consumption entirely, which triggered a correction that may have affected some accounts during the fix window. All of these issues have been marked as resolved by the Search Atlas engineering team. If you topped up recently and still see an exhausted quota, the steps below will help you confirm your current balance and get indexed quickly. 🛠️ Steps to Resolve a Quota Sync Issue 1. Navigate to the URL Indexer. Go to Left sidebar → Authority → Indexer (URL Indexer). 2. Check your displayed quota. Look at the quota counter at the top of the page. If it still reads zero or exhausted, proceed to the next step. 3. Hard-refresh the page. Press Ctrl + Shift + R (Windows/Linux) or Cmd + Shift + R (Mac) to force a full reload. This clears any cached quota display and pulls the latest data from the server. 4. Verify your Hyperdrive Credit balance. Check your account billing or credits section to confirm the top-up transaction completed and that credits were deducted. If credits were deducted but quota is still zero after a refresh, this is a billing discrepancy that requires manual review. 5. Wait up to 5 minutes. In rare cases, quota sync can take a few minutes to propagate. Refresh again after waiting briefly. 6. Retry submitting your URLs. Once quota appears correctly, submit your backlink URLs for indexing as normal through the URL Indexer interface. 💡 Tips for Indexing Large Batches of Backlinks - Submit in batches. If you have hundreds or thousands of URLs, break them into smaller batches of 100–500 URLs. This makes it easier to track progress and identify any URLs that fail validation. - Use valid URL formats. The URL Indexer validates each URL before processing. Ensure all submitted URLs include the full protocol (e.g., https://) and have no spaces or special characters. - Monitor quota consumption. After each batch submission, check the quota counter to confirm URLs were accepted and quota was deducted as expected. - Top up proactively. If you regularly purchase backlinks in large volumes, consider topping up your URL Indexer quota before you need it to avoid delays. ❓ Frequently Asked Questions Will I be charged twice if there was a sync error? The engineering fixes ensure that Hyperdrive Credits are only deducted once per valid top-up and that the correct quota is awarded. If you believe you were charged without receiving quota, contact support via the chat widget so the team can audit your transaction history and issue any necessary correction. Can I use Hyperdrive Credits for anything other than URL Indexer top-ups? Hyperdrive Credits are used for specific Authority-building features. They are not applicable to AI generation quota or other unrelated platform features. If you received guidance stating otherwise, please disregard it — it was inaccurate. What if my quota shows correctly but URLs are not being indexed? Confirm that your URLs pass validation (correct format, publicly accessible). If valid URLs are submitted but not processed within a reasonable timeframe, reach out via the chat widget for investigation. 🆘 Still Need Help? If you have confirmed that Hyperdrive Credits were deducted but your URL Indexer quota was not updated after following the steps above, our team can manually audit your account and restore any missing quota. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔑 Fix Instant Indexing Token Generation Errors Fast

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

🔧 Fix GSC Indexing Access Toast Surface Errors

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

🔍 Fix Dashboard Issue Count and Page Indexing Problems

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

🔍 Fix Keyword Cannibalization and Unindexed Pages

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

🔍 Diagnose Canonical Tags and Google Indexing Issues

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

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

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

🔑 Fix Service Account Provisioning for Instant Indexing

🧭 Overview Instant Indexing in Search Atlas uses a dedicated Google service account to submit URLs directly to Google's Indexing API. Before any URLs can be submitted, that service account must be granted Owner-level access inside Google Search Console (GSC). Until ownership is confirmed, the Has Access flag in your Search Atlas dashboard remains False and no indexing requests will process. Two common approaches fail to satisfy this requirement: the OTTO auto-provisioning flow and the WordPress plugin method. Both are blocked because Google does not allow service account email addresses to claim GSC ownership through automated requests alone. Ownership must be explicitly delegated by a verified human owner inside GSC. The only supported path is the provisioning flow built into the Search Atlas dashboard, paired with a manual ownership grant in GSC. ⚠️ Why Auto-Provisioning and the WP Plugin Fail Understanding why these approaches are rejected saves time before you begin the correct process. - OTTO auto-provisioning: OTTO generates a service account and attempts to register it automatically. Google's Indexing API requires the service account to hold Owner permission in GSC — a level that Google restricts to manual grants by an existing verified owner. Automated registration requests are rejected at Google's end, so ownership is never confirmed regardless of how many times the flow runs. - WordPress plugin approach: The WP plugin authenticates at the site level but cannot elevate a service account to Owner in GSC. Plugin-level credentials carry Full User permission at best, which is insufficient for the Indexing API. Google silently ignores indexing submissions from accounts below Owner level. - Google Cloud Console only: Creating or downloading a service account key directly from Google Cloud Console without linking it through the Search Atlas dashboard means the platform never registers the account. The Has Access flag is set by Search Atlas after verifying the ownership grant, so bypassing the dashboard leaves it permanently False. ✅ What the Has Access Flag Actually Means The Has Access flag is a status indicator inside the Search Atlas dashboard. It reflects whether the service account attached to your property has been verified as an Owner in GSC and is ready to submit indexing requests. - False: The service account exists but Google has not confirmed Owner-level permission. No URLs will be submitted. - True: Search Atlas has verified that the service account holds Owner permission in GSC. Instant Indexing submissions are active. The flag flips to True only after you complete both steps: provisioning the service account through the Search Atlas dashboard and manually granting that service account Owner-level permission inside GSC as a verified human owner. 🛠️ How to Correctly Set Up Instant Indexing 1. Navigate to Authority → Indexer (URL Indexer) in your Search Atlas dashboard and use the built-in provisioning flow to generate your dedicated service account. 2. Copy the service account email address provided by the dashboard. 3. Log in to Google Search Console with an account that already holds Owner verification for your property. 4. Go to Settings > Users and permissions and add the copied service account email as an Owner. 5. Return to your Search Atlas dashboard. Once Google confirms the ownership grant, the Has Access flag will update to True and Instant Indexing submissions will become active. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

💡 Meta Keywords, Indexing, and Report Discrepancies Explained

🔍 Overview This article answers three common questions from Search Atlas users: whether deploying meta keywords affects your Google rankings, whether Search Atlas supports instant indexing, and why click counts in shared reports may not match what you see in Google Search Console (GSC). Read on for clear, practical answers to each. 🏷️ Do Meta Keywords Impact Site Rankings? The short answer is no. Google officially stopped using the meta keywords tag as a ranking signal in 2009. Adding or removing meta keywords will not improve or hurt your position in Google search results. Other major search engines, including Bing, also ignore or heavily discount this tag. Here is what you should know: - Meta titles and meta descriptions do matter. They influence click-through rates and how your pages appear in search results. - Meta keywords are a legacy field. Including them causes no harm, but they provide no SEO benefit with modern search engines. - If you are auditing existing pages, do not prioritise adding or removing meta keywords. Focus your effort on optimising meta titles and descriptions instead. Search Atlas includes tools to help you generate and manage meta titles and descriptions. Refer to the platform's navigation to locate the relevant meta tag features. ⚡ Does Search Atlas Support Instant Indexing? Search Atlas does not currently offer a dedicated instant indexing feature integrated directly into the platform. To get pages indexed as quickly as possible, you can take the following general steps: 1. Use Google Search Console directly. The fastest way to request indexing for a specific URL is to use the URL Inspection tool inside GSC and submit a crawl request for that page. 2. Submit your XML sitemap. Make sure your sitemap is submitted and up to date inside GSC so Google can discover your pages efficiently. 3. Check for technical crawl issues. Ensure there are no technical barriers preventing Googlebot from discovering or crawling your pages. Search Atlas provides audit tools to help identify such issues — refer to the platform's navigation to locate them. 4. Build internal links. Pages with strong internal linking are discovered and crawled faster. Use Search Atlas's content planning tools to structure a well-connected site. If instant indexing via the Google Indexing API is a feature you would like to see added to Search Atlas, you can submit a feature request through the support chat widget. 📊 Why Do Click Counts in Shared Reports Not Match GSC? It is common to notice differences between the click data shown in a Search Atlas shared report and the data you see directly in Google Search Console. This discrepancy is expected and typically has the following causes: - Date range differences. The date range selected when the shared report was generated may not match the date range you are currently viewing in GSC. Always confirm both are set to the same period before comparing numbers. - Data sampling and delays. GSC data can be delayed by several days and may be subject to sampling, meaning the numbers you see in GSC at any given moment may not yet be final or complete. - Report snapshot timing. A shared Search Atlas report captures data at the time it was generated. If GSC updates its data after the report was shared, the numbers will diverge. - Filter differences. GSC allows filtering by country, device, search type, and other dimensions. If your GSC view has active filters that differ from how the Search Atlas report was configured, click counts will not match. To resolve a discrepancy, compare both sources using the same date range, with no additional filters applied, and allow at least 48–72 hours for GSC data to stabilise before drawing conclusions. If numbers still appear inconsistent after accounting for the above, note the specific date range, the values shown in each source, and the report link so that our team can investigate further. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔧 Fix Google Search Console Indexing Access Errors

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

⚡ Fix Instant Indexing Service Account Access

What Is Instant Indexing and Why Does Access Fail? Search Atlas's Instant Indexing feature uses a Google service account to submit URLs directly to Google for faster indexing. Before any URLs can be submitted, that service account must be granted the appropriate ownership access to your property in Google Search Console (GSC). The most common reason service account provisioning fails is that the required ownership conditions in GSC have not yet been met. Both automated and manual setup approaches will be blocked if those conditions are not satisfied first. How to Resolve Service Account Provisioning Issues If your Instant Indexing service account provisioning is failing, the issue typically relates to GSC ownership permissions not being correctly configured for your property. To resolve this, you will need to ensure that the Search Atlas service account has been granted the correct level of access in GSC for your site. Contact the Search Atlas support team with the details listed below so they can confirm what access is missing and guide you through the exact steps needed for your specific setup. What to Have Ready When Escalating When reaching out, please have the following information ready so the team can assist you as quickly as possible: - Your site URL as it appears in Google Search Console - The service account email address associated with your Search Atlas account - Any error messages you received during provisioning - The timestamp of when the provisioning failure occurred If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. Additional Notes OTTO auto-provisioning fails because Google rejects automated ownership registration. WP plugin grants only Full User permission, insufficient for Indexing API. Creating keys in Google Cloud Console without linking via Search Atlas dashboard leaves Has Access flag permanently False.

🔍 Fix 'Unable to Activate Indexing' Error in GSC

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

🔄 Fix Page Indexability Status Constantly Flipping

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

🔍 Fix Instant Indexing Queue Stuck Issues

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

🛠️ Fix Post-Migration 404 and Indexing Issues

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

🛠️ Shopify Installation Status and OTTO Indexing Delays

🔍 Overview After connecting a new Shopify store to Search Atlas, it is common to see a status message that reads not installed correctly on the dashboard. In most cases, this is not an error. It simply means the platform has not yet finished verifying your installation. The status is temporary and resolves automatically once OTTO finishes indexing your website. This article explains what to expect and how to confirm everything is working properly. ⏳ Why the Status Shows 'Not Installed Correctly' When you add a Shopify site, Search Atlas needs time to crawl your store, verify the connection, and begin pulling data into OTTO. During this window, the dashboard may display a status that looks like a failure even when the installation was completed successfully. Think of it as a loading screen. The installation itself is complete; OTTO simply needs time to verify and catalog your site's data before the status updates. - Verification typically completes within 24 to 48 hours after installation. - OTTO indexing — where your site's pages are fully processed and SEO recommendations are generated — can take up to 72 hours for larger stores. - Indexing time varies depending on the size of your Shopify store. Smaller stores will typically complete indexing faster, while larger stores with more pages may take longer. - The status message updates automatically once verification is confirmed. No manual refresh or reinstallation is needed. ✅ How to Confirm Your Shopify Site Is Connected Correctly While you wait for the status to update, you can take a few steps to confirm the installation was completed on your end. 1. Log in to your Shopify Admin panel and navigate to Apps. 2. Confirm that the Search Atlas app appears in your installed apps list. 3. Return to Search Atlas and go to Left sidebar → OTTO SEO → SEO Automation (URL: /seo-automation-v3). 4. Check whether your Shopify domain appears in the site list. If it does, the connection was registered successfully. 5. Go to Left sidebar → Site Metrics (Site Explorer) (URL: /site-explorer/list) and select your Shopify domain. If site data is beginning to populate, the installation is working correctly. 🚀 What Happens After OTTO Finishes Indexing Once OTTO completes the indexing process, you will see the following changes in your dashboard: - The installation status updates to installed correctly. - OTTO begins generating SEO automation recommendations for your Shopify pages, including titles, meta descriptions, and schema. - Site data — such as keyword rankings and traffic metrics — starts appearing under Site Explorer. You do not need to take any action to trigger this. The process runs automatically in the background. ⚠️ When You Should Be Concerned In most cases, waiting 48–72 hours resolves the status message. However, reach out for support if any of the following apply: - More than 72 hours have passed and the status still shows not installed correctly. - Your Shopify domain does not appear in the OTTO SEO V3 or Site Explorer sections after 48 hours. - You receive an explicit installation error message (distinct from the pending status). - You accidentally uninstalled and reinstalled the app and are unsure whether the reconnection was successful. - OTTO is not generating any data after a reasonable indexing window has passed. If any of these situations occur, contact our support team with your Shopify site name, the approximate time of installation, and a description of what you are seeing so we can investigate further. 💡 Tips to Avoid Installation Issues - Make sure you complete the full connection flow in Search Atlas without closing the browser tab mid-process. - Do not uninstall and reinstall the app within the first 24 hours — this resets the verification timer. - Ensure your Shopify store is publicly accessible (not password-protected) so Search Atlas can crawl it successfully. 🙋 Need More Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🔄 URL Indexer Quota Looks Wrong or Hasn't Reset

Overview Some customers have noticed their URL Indexer quota displaying an unexpected number or failing to reset as expected. In most cases, this is caused by a backend data error that applied an incorrect quota to the account — not a billing issue or a platform bug you can fix yourself. This article explains what the correct quota is for your plan, why discrepancies happen, and what self-serve steps to try before contacting support. What Is the Correct URL Indexer Quota? Your URL Indexer quota depends on your current subscription plan. You can verify your exact plan allowance by checking your billing settings inside your Search Atlas account. If your quota is displaying a number that does not match what your plan entitles you to, and you have not purchased additional top-up credits, this is likely a data error on our side — not a genuine entitlement. Why Does This Happen? Quota mismatches can occur due to backend data errors that apply an incorrect quota to an account. This is not something caused by your actions, and it is not a billing error you need to resolve through your payment provider. The incorrect quota may remain on your account until it is reviewed and corrected. Self-Serve Steps to Try First Before contacting support, work through the following steps — many quota display issues can be resolved or clarified without agent intervention: 1. Hard-refresh the URL Indexer page. Press Ctrl + Shift + R (Windows) or Cmd + Shift + R (Mac) to force a full page reload and clear any cached display values. Sometimes the quota counter shown is stale and will update after a fresh load. 2. Log out and log back in. Sign out of your Search Atlas account completely, then sign back in. This forces your session to pull the latest account data, including your current quota balance. 3. Confirm your plan in billing settings. Go to your billing settings inside Search Atlas and verify which subscription plan you are on. Compare the listed quota entitlement for that plan against what the URL Indexer page is showing. 4. Check for recent top-up purchases. If you have purchased additional URL Indexer credits, confirm those purchases appear in your billing history. Top-up credits are added on top of your base plan quota, so the total displayed may be higher than your base allowance — this is expected behaviour. 5. Check when your quota is scheduled to reset. URL Indexer quotas reset on a monthly billing cycle. Your reset date is tied to your subscription renewal date, which you can find in your billing settings. If your reset date has not yet passed, the quota will not refresh until that date is reached. 6. Try switching plans and switching back (if applicable). If you recently changed subscription plans and suspect the quota did not update correctly, navigating to your billing settings and confirming the active plan is current can sometimes surface a stale quota that needs a backend sync. If you have worked through all of the steps above and your quota is still displaying an incorrect number or has not reset after your expected renewal date, the issue requires a manual backend correction. When to Contact Support Reach out to our support team if: - Your quota has not reset more than 24 hours after your billing renewal date. - The number shown does not match your plan entitlement and a hard-refresh or re-login did not correct it. - You believe a top-up purchase was applied incorrectly or is missing from your balance. When you contact us, please have the following ready: your current plan name, the quota figures displayed on the URL Indexer page, and any relevant top-up purchase dates. This allows our team to investigate and apply the correct quota as quickly as possible. You can reach our support team via the chat widget inside your Search Atlas account — we're happy to help get this sorted for you.

🛠️ GSC & Bing Indexing, AI Premium Credits, and Domain Knowledge Network Guide

Fix GSC Instant Indexing and Bing Indexing issues, recover missing AI Premium credits, and build a cluster-driven content strategy with the Domain Knowledge Network (DKN). ⚠️ Content AI Processing Errors in the Article Editor If you see an error when editing the About The Author section or other AI-assisted fields in the article editor, this is a known intermittent issue with the Search Atlas content AI processing pipeline. - Check status.searchatlas.com for the latest incident updates before contacting Support. - No action is needed on your end — the Search Atlas team is actively mitigating the issue. - Wait a few minutes, then try editing again. Once the incident resolves, all AI-assisted article fields will function as expected. 🔍 GSC Instant Indexing Troubleshooting Search Atlas GSC Instant Indexing submits your URLs directly to Google Search Console for faster crawling and indexing. If submissions are not going through, follow these steps: 1. Go to Settings → Integrations and confirm your Google Search Console account is connected. 2. Verify the correct GSC property — either a domain property or a URL-prefix property — is selected. 3. Re-submit the affected URL from the Instant Indexing tool. If your connection is confirmed active and submissions still fail, contact Search Atlas Support with the affected URLs so the team can investigate further. 🔗 Bing Indexing Troubleshooting Search Atlas Bing Indexing uses the Bing URL Submission API, which requires root access — admin-level control over your domain's DNS or server — to verify ownership with Bing Webmaster Tools. - If your hosting provider controls DNS on your behalf, Bing Indexing cannot be configured until you obtain root access to add TXT verification records. - Confirm root-level DNS or server access before connecting Bing Indexing in Search Atlas. - If access is confirmed but the integration is still failing, contact Search Atlas Support to escalate the issue. Once domain ownership is verified and the integration is active, Search Atlas will submit your URLs to Bing automatically. 💳 Missing AI Premium Credits — Recurring vs. Non-Recurring Search Atlas AI Premium credits come in two types with different restoration rules. Understanding the difference helps set the right expectations when you contact Support. - Recurring credits refill monthly as part of your plan. If they appear missing or depleted in error, Search Atlas Support can restore them directly. After restoration, reload your browser tab to see the updated balance. - Non-recurring credits are one-time top-up credits. Once consumed, they cannot be restored by Support. When contacting Support about missing credits, specify whether the shortfall is in your recurring or non-recurring balance so the correct action can be taken right away. 🗺️ How to Use the Domain Knowledge Network (DKN) Strategically The Domain Knowledge Network (DKN) maps your domain's topical coverage — showing which subject clusters you own, which are partially covered, and where gaps exist. Use that gap data to drive your content calendar instead of planning topics at random. 📌 Find Your Next Articles in the Gap Map Open the Topical Maps and look for cluster gaps — topic areas where your domain has little or no coverage. Each gap signals a missing article. Treat the full gap list as your prioritized content backlog. 🎯 Fill Partial Clusters Before Opening New Topics 1. Identify clusters where you already have some content but coverage is incomplete. 2. Prioritize filling those clusters first — completing a partial cluster builds topical authority faster than starting a brand-new topic area from scratch. 3. Follow the cluster structure, not individual keyword impulses. 📈 Rank Your Gaps by Authority Potential Within your gap list, move to the top any clusters where your existing domain equity gives you a competitive advantage — topics where you are closest to establishing clear authority. 🔗 Combine the DKN with the Search Atlas Content Planner Use the DKN alongside the Search Atlas Content Planner to convert cluster gaps into scheduled, briefed articles with target keywords, structure recommendations, and word-count guidance. This keeps your strategy cluster-driven from planning through publication. For step-by-step walkthroughs, visit the Search Atlas documentation and sign up for a live DKN training session. 🌀 You now know how to troubleshoot GSC and Bing Indexing failures, recover recurring AI Premium credits, and apply a gap-first, cluster-driven approach with the Domain Knowledge Network — check status.searchatlas.com any time to monitor for active incidents affecting Search Atlas tools.

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

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

⚡ Fix Instant Indexing HTTP 400 Activation Error

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