Troubleshooting: Publishing, Domains & SSL

🛠️ Fix Deleted Pages and 404 Errors in Website Studio

🛠️ Fix Wix Content Genius Publish-Sync Issues

🔧 Fix DNS Verification Failures in Website Studio

🔗 WebsiteStudio Homepage Canonical Redirects

🏠 Why the homepage cannot redirect In WebsiteStudio, the homepage is the starting point of your site. It is connected to your main domain, such as https://example.com/, so it cannot be redirected to another page or URL from within the editor. If you try to redirect the homepage, you may see the message: “Your home page is where the site starts, so it can't be sent elsewhere.” This is expected behavior, not an error. 🔗 Canonical tags and redirects are different A canonical tag tells search engines which URL should be treated as the main version of a page. It does not send visitors to another URL. A redirect automatically sends visitors and search engines from one URL to another. WebsiteStudio does not support redirecting the root homepage to another destination. WebsiteStudio pages use self-referencing canonical URLs by default. This means each page identifies its own URL as the preferred version unless the platform provides another supported configuration. 🛠️ What you can do instead - Keep the homepage as your main landing page: Add buttons, navigation links, or calls to action that guide visitors to the page you want them to see. - Use a separate page for campaigns: Create a dedicated landing page with its own URL instead of redirecting the homepage. - Update your navigation: Change the menu, logo link, or homepage content so visitors can quickly reach the intended destination. - Use your preferred domain: If you are changing domains, update the site’s domain configuration and verify the new homepage rather than redirecting the homepage inside WebsiteStudio. 🔍 Check the correct URL 1. Open the published site in a browser. 2. Confirm that the homepage loads at the root domain, with no unexpected path such as /welcome. 3. Open individual pages using their full URLs. 4. Check that each page has the expected canonical URL and is not marked noindex. If a page unexpectedly redirects to the homepage, cannot be opened directly, shows an incorrect canonical URL, or returns an error instead of a normal not-found page, this may indicate a site configuration or platform issue. Record the affected URL and the steps that reproduce the behavior before contacting support. 💡 Recommended homepage setup Keep the homepage accessible at your main domain and use it to explain your site, establish your brand, and direct visitors to important pages. For SEO, make sure the homepage has a unique title, description, relevant content, and a self-referencing canonical URL. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🖼️ Fix Brand Vault Image 404 Errors in Website Studio

🔍 Overview When you add images from the Brand Vault to a landing page in Website Studio, you may encounter a 404 error — meaning the image fails to load and displays a broken link instead. In some cases, an error pop-up also appears during page preview and cannot be dismissed. This article explains what causes this issue and walks you through the steps to resolve it. ⚠️ What Causes This Error This issue is triggered by a known bug where Brand Vault filters carry over incorrectly into the image path, causing the image URL to break. Specifically: - The image URL generated by the Brand Vault includes an invalid filter segment (e.g., /images/ is appended incorrectly), making the path unresolvable. - This can affect images added to landing pages, clone mode pages, and PPC sites built inside Website Studio. - The bug has also been known to prevent images from being added to a page even after a successful Brand Vault upload. The underlying engineering fixes for this bug have been deployed. If you are still experiencing the issue, follow the steps below to resolve it on your end. 🛠️ How to Fix Brand Vault Image 404 Errors 1. Navigate to Website Studio. In the left sidebar, click Website Studio (URL: /website-studio). 2. Open your affected landing page and locate the section where the broken image appears. 3. Remove the broken image. Click on the image element and delete it from the page. 4. Re-open the Brand Vault image picker. Click the image placeholder or the insert image option within the page editor. 5. Re-select your image from Brand Vault. Browse to the correct image and insert it fresh. Do not use a previously copied image URL — always select directly from the Brand Vault picker to ensure a clean URL is generated. 6. Preview the page again. Click the preview option to confirm the image now loads correctly and the error pop-up no longer appears. 7. Save and publish your page once the image displays as expected. 💡 Tips to Prevent This Issue - Always upload images to the Brand Vault before building or editing your landing page, so the assets are fully processed and available. - Avoid duplicating or copy-pasting image URLs from previous pages — always re-select images through the Brand Vault picker. - If you are working with clone mode pages, re-link any Brand Vault images after cloning, as image references may not carry over correctly. - After uploading a new image to the Brand Vault, wait a few seconds before inserting it into a page to allow the asset to finish processing. ✅ Confirming the Fix Once you have re-inserted the image directly from the Brand Vault picker, preview your page to verify: - The image displays correctly without a broken icon or placeholder. - No 404 error pop-up appears during preview. - The published version of the page renders the image as expected for visitors. If the image still fails to load after following these steps, the asset itself may not have uploaded successfully. Try deleting and re-uploading the image to the Brand Vault, then insert it into the page again. 🙋 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 Table Formatting Loss When Publishing Articles

🔍 Overview When you publish an article from Search Atlas to a connected CMS, tables may lose their formatting — borders disappear, columns collapse, or the entire table renders as plain text. This is a known issue that has been resolved through platform updates, but a few steps on your end can ensure tables transfer cleanly across all your CMS connections. ⚙️ Why This Happens Table formatting can break during publishing for a few common reasons: - HTML sanitisation by the CMS: Some CMS platforms strip or rewrite certain HTML tags — including <table>, <thead>, and <td> — when content is received via API, causing borders and structure to disappear. - Block conversion conflicts: When Search Atlas converts your article into CMS-compatible blocks, tables may be flattened into a single content block instead of being preserved as structured elements. - Missing table styles: The CMS theme may not apply default border styles to tables, making them appear invisible even when the HTML is technically correct. ✅ Recommended Fixes 1. Re-publish the article after the platform update. A fix preserving table structure during CMS publishing has been deployed. Open your article in the Content Editor, make no changes, and click Publish again. This forces the updated export logic to run. 2. Check your CMS connection settings. Navigate to your CMS integrations and confirm that the connection is active and using the latest version. Disconnect and reconnect any affected CMS if the issue persists after re-publishing. 3. Verify your CMS theme supports table styles. In WordPress and similar platforms, add the following CSS to your theme's stylesheet or custom CSS panel to restore visible table borders: 1. Test with a single CMS connection first. If you have multiple connections affected, re-publish to one CMS and confirm the table renders correctly before pushing to the remaining five. This helps isolate whether the issue is platform-wide or specific to one integration. 2. Avoid copying table content from external sources. If you paste a table from Google Docs, Microsoft Word, or another tool into the Content Editor, the underlying HTML may carry incompatible styles. Build tables directly inside the Search Atlas editor when possible. 3. Open the left sidebar → Content (Content Genius tab). 4. Locate the article with the formatting issue and click to open it. 5. Scroll through the article to confirm the table appears correctly inside the editor. 6. Click Publish and select your target CMS connection. 7. Once published, visit the live URL or CMS preview to confirm the table borders and columns are intact. 8. Repeat for each additional CMS connection as needed. - Do not manually edit raw HTML in your CMS to re-add table tags — this can be overwritten on the next publish. - Do not delete and recreate CMS connections as a first step; re-publishing is sufficient in most cases. - Do not use the CMS's built-in editor to reformat the table after publishing, as subsequent publishes from Search Atlas may overwrite those changes. - Confirm you are using a supported CMS version. - Check that your CMS API key has write permissions, which are required for full HTML block publishing. - Clear the CMS page cache after publishing, as a cached version may still display the old formatting. table, th, td { border: 1px solid #ccc; border-collapse: collapse; padding: 8px; } This ensures tables display correctly regardless of how your theme handles default styles. 📋 Step-by-Step: Re-Publish an Article 🚫 What to Avoid 💡 Still Seeing the Issue? If tables are still not rendering correctly after re-publishing, try the following quick checks: 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.

🌐 Publishing Landing Pages to Your WordPress Domain

🗺️ Overview Some customers have been told by a previous Search Atlas representative that pages can be added directly to an existing domain — without creating a subdomain or a new site. This article clarifies exactly what is and is not possible today, so you can choose the right publishing path for your needs. ⚠️ Can I Add Pages Directly to My Current Domain? No — this is not currently supported. At this time, Website Studio does not support publishing a landing page directly to the root of an existing domain (for example, yourdomain.com/new-page) without a technical integration step. If a previous representative indicated otherwise, we sincerely apologise for any confusion. That capability, if it was ever available, is not part of the current platform. To publish a page from Website Studio to your domain, you must use one of two supported methods: - Subdomain publishing — for example, landing.yourdomain.com - Subpath publishing via WordPress plugin — for example, yourdomain.com/page-name, using the Search Atlas WordPress plugin Both methods require a one-time configuration step. Neither permanently alters your existing site structure or takes down any current pages. 🔌 Option 1 — Subdomain Publishing A subdomain keeps your landing pages completely separate from your main WordPress site and requires a small DNS change. 1. In Website Studio, open your project and go to Settings → Domain. 2. Choose Connect a subdomain and enter your desired subdomain (for example, landing.yourdomain.com). 3. Log in to your domain registrar or DNS provider. 4. Create a CNAME record pointing your chosen subdomain to the value shown in Website Studio. 5. Save the DNS record. Propagation typically takes 5–30 minutes. 6. Return to Website Studio and click Verify Connection. 7. Publish your page. It will go live at your subdomain URL. Your existing WordPress site at yourdomain.com is completely unaffected. 🔗 Option 2 — Subpath Publishing via WordPress Plugin If you want pages to appear under your main domain (for example, yourdomain.com/offer), you can do this using the Search Atlas WordPress plugin. This is the closest available option to adding a page directly to your domain, and it does not require any DNS changes. 1. Log in to your WordPress admin dashboard. 2. Go to Plugins → Add New → Upload Plugin and upload the Search Atlas plugin .zip file provided by Search Atlas. 3. Install and activate the plugin. 4. Inside the plugin settings, connect it to your Search Atlas account using your API key. You will find your API key under Account Menu (avatar) → Settings → API Keys in the Search Atlas platform. 5. In Website Studio, go to Settings → Domain for your page and select Publish to WordPress. 6. Choose the subpath slug you want (for example, /offer) and confirm. 7. The page will appear at yourdomain.com/offer without touching your existing WordPress content. Note: Your WordPress site must be self-hosted (not WordPress.com) and you must have admin access to install plugins. 📋 Comparison at a Glance - Root domain publishing (yourdomain.com/page) — Not supported without the WordPress plugin. Requires plugin installation; no DNS change needed. - Subpath via WordPress plugin (yourdomain.com/slug) — Supported. No DNS change. Requires plugin install and admin access. - Subdomain (landing.yourdomain.com) — Supported. Requires one CNAME DNS record. No plugin needed. - Standalone new domain — Supported. Requires domain connection via DNS. ❓ What If I Was Told Something Different? We take representative communications seriously. If you were given specific instructions or commitments by a previous Search Atlas team member that do not match the options described here, please reach out so we can review your account history and find the best path forward. The subpath-via-plugin method is the closest current equivalent to what may have been described, and our team can walk you through the setup. 💡 Quick Troubleshooting Tips - If your subdomain shows a DNS error after setup, allow up to 48 hours for full propagation before re-verifying. - If the WordPress plugin connection fails, confirm your API key is copied exactly with no extra spaces. - If your subpath page is not appearing on WordPress, check that no existing page or post is using the same slug. - If you do not have plugin install access on your WordPress site, the subdomain option is your best alternative. 🆘 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 Blog Page Redirects and WordPress Sync Issues

🔍 Overview This article covers an issue that can affect your publishing workflow in Search Atlas: articles created in Content Genius failing to sync to your WordPress site. This is a known issue that our engineering team has been made aware of. ⚠️ Blog Page Access Opening a Website Studio blog page URL directly loads that page; there is no redirect. 🔗 Known Issue: Content Genius to WordPress Sync Failures If articles you create in Content Genius are not syncing to your WordPress site, this is a known issue affecting some accounts. Because the root cause requires a backend investigation, there are no self-serve steps that are confirmed to resolve it. When escalating, please have the following ready: - The name of your Search Atlas project or workspace affected. - The exact error message or behaviour you see when attempting to sync (e.g. sync appears to succeed but content does not appear in WordPress, or an error is displayed). - The URL of your WordPress site. - The approximate date and time when the issue first occurred. Our team will investigate the connection between your Content Genius account and your WordPress destination on the backend. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix WordPress 'None Response' Publishing Errors

🔍 What Is the 'None Response' Error? When you attempt to publish an article directly to WordPress from Search Atlas, you may see an error message that reads None Response. This means Search Atlas sent the publish request to your WordPress site but received no valid reply in return. The connection was either blocked, timed out, or rejected before it could complete. This is almost always caused by a configuration issue on your WordPress site rather than a problem with Search Atlas itself. ⚙️ Common Causes of This Error - REST API is disabled: Search Atlas uses the WordPress REST API to publish content. If a plugin or server setting has disabled it, all publish requests will fail. - Incorrect API credentials: An invalid username, password, or Application Password will cause the connection to be rejected silently. - Security plugins blocking requests: Plugins like Wordfence, iThemes Security, or Cloudflare WAF rules can block external API calls from Search Atlas. - SSL certificate issues: An expired or misconfigured SSL certificate on your WordPress domain can prevent a secure connection from being established. - Server timeout or resource limits: Shared hosting environments with low memory or execution time limits may drop the request before a response is sent. 🚀 Step-by-Step Resolution 1. Verify your WordPress connection settings. In Search Atlas, go to the top-right avatar → Settings → Integrations / CMS Connectors and confirm that the WordPress site URL, username, and Application Password are all entered correctly. The URL must be a valid domain URL (for example, https://example.com). 2. Confirm the REST API is active. Open a new browser tab and navigate to yoursite.com/wp-json/wp/v2/posts. If you see a JSON response with post data, the REST API is working. If you see an error or blank page, the REST API is disabled and needs to be re-enabled in your WordPress settings or by deactivating the plugin that is blocking it. 3. Regenerate your Application Password. In your WordPress dashboard, go to Users → Profile, scroll to the Application Passwords section, delete the existing entry for Search Atlas, and create a new one. Copy the new password immediately and update it in Search Atlas. 4. Temporarily disable security plugins. Deactivate plugins such as Wordfence, All In One WP Security, or similar tools one at a time. Attempt to publish again after each deactivation to identify which plugin is blocking the request. Once identified, add Search Atlas IP addresses to the plugin's allowlist or whitelist. 5. Check your SSL certificate. Visit whatsmycertificate.com or a similar tool and enter your domain to confirm the SSL certificate is valid and not expired. An invalid certificate will cause secure API calls to fail silently. 6. Contact your hosting provider. If none of the above steps resolve the issue, ask your hosting provider to confirm that outbound REST API requests are permitted and that execution time and memory limits are sufficient to handle publishing requests. 💡 Tips to Prevent This Error in Future - Use a dedicated Application Password for Search Atlas rather than your main account password. - Avoid using security plugins that blanket-block all REST API requests unless you can configure per-application exceptions. - Keep your WordPress core, plugins, and themes updated to reduce conflicts that can affect API behavior. - Test your WordPress connection inside Search Atlas after any major site update or hosting migration. 📊 Challenge Access Eligibility Some Search Atlas features, including certain publishing challenges or content campaigns, require your WordPress integration to be fully verified and active before you can participate. If you are seeing a message indicating you are not eligible for a challenge, the most likely reason is that your WordPress connection has not been successfully established or has recently disconnected due to one of the errors described above. To restore eligibility, resolve the None Response error using the steps above, then re-verify your WordPress connection inside Search Atlas. Once the connection returns a successful status, challenge access should be restored automatically within a few minutes. 🆘 Still Need Help? If you have followed all of the steps above and the error persists, If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

Fix WordPress Content Genius 500 Error on Hostinger

Overview Some users hosting WordPress sites on Hostinger have encountered a 500 Internal Server Error when attempting to sync articles from Content Genius to their WordPress site using the Search Atlas plugin. This error is typically related to a backend conflict between the Search Atlas plugin and the Hostinger hosting environment. Steps to Resolve the 500 Error Try the following steps in order to resolve the issue on your own before contacting support: 1. Update the Search Atlas plugin. Make sure you are running the latest version of the Search Atlas WordPress plugin. Go to your WordPress admin dashboard, navigate to Plugins > Installed Plugins, and update Search Atlas if an update is available. 2. Deactivate and reactivate the plugin. In Plugins > Installed Plugins, deactivate the Search Atlas plugin, then reactivate it. This can clear authentication or connection state issues that cause 500 errors. 3. Re-enter your API credentials. After reactivating, go to the Search Atlas plugin settings and re-save your API key or authentication credentials to re-establish the connection between Content Genius and your WordPress site. 4. Check for plugin conflicts. Temporarily deactivate all other plugins, then attempt the sync again. If the sync succeeds, reactivate your other plugins one at a time to identify the conflicting plugin. 5. Increase PHP memory limit. Hostinger environments sometimes have low PHP memory limits that can trigger 500 errors. In your Hostinger control panel or via your wp-config.php file, try increasing the PHP memory limit (for example, add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php). 6. Retry the sync. Once you have completed the steps above, return to Content Genius and attempt to sync the article again. If the Error Persists If you have tried all of the steps above and the 500 error continues, please contact our support team with the following information so we can investigate further: - Your WordPress site URL - The article you were attempting to sync - Any error messages or screenshots you can share You can reach our support team through the live chat widget in the bottom-right corner of the platform — type human teammate to reach a member of the team, and we will be happy to assist.

🛠️ Fix WordPress Publishing Stuck in Content Genius

🔍 Overview Some customers find that when they try to publish an article from Content Genius directly to WordPress, the Create button keeps spinning and resets without publishing anything. This guide explains the most common causes and the steps you can take to resolve the issue. ⚙️ Common Causes - Stale generation loop: Content Genius can occasionally get stuck in a background status-polling loop, preventing new publish actions from completing. - Article stuck at Step 1: If article generation did not fully complete, the article may be in an incomplete state that blocks export. - Incorrect WordPress connection: The platform may be referencing an outdated or misconfigured WordPress CMS connector, causing publish requests to fail silently. - Syncing the original draft instead of your edits: A known issue can cause the export to send the original AI-generated draft rather than your latest saved version, which may also interrupt the publish flow. ✅ Step-by-Step Fixes 1. Refresh and check article status. Go to Left sidebar → Content and open the Content Genius listing table. If the article shows a loading or generating status, wait two to three minutes and refresh the page. If it remains stuck, continue to the next step. 2. Save your edits before exporting. Open the article in the editor. Make sure all your changes are saved — look for a confirmation that the latest version is stored. Do not attempt to publish immediately after making edits without saving first. 3. Re-open the article and retry the Create button. Close the article, return to the Content Genius listing table, reopen the article, and click Create again. A fresh session often clears the loop. 4. Verify your WordPress CMS connector. Navigate to Account Menu (avatar) → Settings → CMS Connectors and confirm that your WordPress site is connected correctly. If you see more than one connection for the same site, remove the duplicate and keep only the active one. Do not add a new connection if one already exists — the platform should detect and use the existing connector automatically. 5. Check your WordPress site permissions. In your WordPress admin panel, confirm that the user account connected to Search Atlas has the Administrator role. Author or Editor accounts cannot connect the plugin, and insufficient permissions can silently block publishing. 6. Try publishing a different article. If the issue affects only one article, it may be in a corrupted state. Try creating a new article and publishing that one to confirm your connection is working. Then retry the original article. 7. Clear browser cache or switch browsers. Occasionally a cached session causes button states to freeze. Clear your cache or open Search Atlas in a different browser and attempt the publish again. 🚫 What to Avoid - Do not click the Create button repeatedly. Multiple rapid clicks can create duplicate publish requests and worsen the loop. - Do not disconnect and reconnect your WordPress site unnecessarily. If a valid CMS connector already exists, adding a new one can cause conflicts. - Do not navigate away mid-generation. If an article is still generating (Step 1 progress visible), leaving the page can interrupt the process and leave the article in a stuck state. 💡 Tips to Prevent This Issue - Always wait for article generation to fully complete before opening the editor or attempting to publish. - Save your edits explicitly before clicking Create to ensure the latest version is exported to WordPress. - Keep only one active CMS connector per WordPress site under Account Menu (avatar) → Settings → CMS Connectors. - Use a supported modern browser such as Chrome or Firefox, kept up to date. 🆘 Still Need Help? If you have followed all the steps above and the Create button is still stuck, our team can investigate your specific account and article state. 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.

🛠️ Blog Posts Showing 404 or NoSuchKey Errors in Website Studio

🔍 What This Issue Looks Like After publishing blog posts in Website Studio — especially if your domain DNS was misconfigured at any point during publishing — your live blog URLs may return one of the following errors: - A 404 page (page not found) - A raw NoSuchKey XML error displayed in the browser These errors can persist even after the DNS issue has been corrected, and re-publishing or editing the posts may not resolve them. ⚙️ Why This Happens This issue is caused by a platform-side sync failure in Website Studio. When a blog post is published under certain conditions — such as during or shortly after a DNS misconfiguration — the article can fail to sync correctly to the Website Studio delivery layer. The post appears published inside the platform but is not properly served on the live site. ✅ Steps to Resolve 1. Confirm your DNS is fully propagated. Before attempting to fix the blog posts, make sure your domain's DNS settings are correctly configured and fully propagated. You can use a free tool like whatsmydns.net to verify your domain is resolving correctly worldwide. 2. Re-publish the affected blog posts. Open Website Studio and navigate to the blog post that is returning the error. Re-save or re-publish the post so the platform can attempt a fresh sync to the delivery layer. 3. Check the live URL again. After re-publishing, wait a few minutes and then reload the blog post URL in your browser. Clear your browser cache or test in an incognito window to rule out a cached error page. 4. Test multiple posts if needed. If you have several affected blog posts, repeat step 2 for each one individually. 📋 What to Expect Going Forward Once the posts are successfully re-published, they will serve correctly on your domain. New blog posts published through Website Studio will also publish correctly without requiring any extra steps. 🚨 If Posts Are Still Returning Errors If you have re-published your posts and the 404 or NoSuchKey errors continue, this may indicate that the sync issue is still affecting your specific project and needs to be reviewed by our team 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. When you reach out, please include: - Your domain name - The URLs of the specific blog posts returning errors

📅 Fix an Invalid Publish Date in Signal Genesys

🗂️ Overview When you try to publish a press release in Signal Genesys and see an "invalid publish date" error, it means the distribution date and time saved on the release does not meet the platform's requirements. This article walks you through the exact location of that field, the rules for setting a valid date, and how to fix access issues if the Signal Genesys portal does not load correctly. 🔍 Where to Find the Distribution Date Field The publish date in Signal Genesys is called the Distribution Date. It is not edited inside Search Atlas — you must go directly into the Signal Genesys portal to update it. Follow these steps: 1. From your Search Atlas dashboard, open Content in the left-hand navigation menu, then select Press Releases. 2. Locate the press release showing the error and click its title to open the detail view. 3. Click the View in Signal Genesys button. This opens your release inside the Signal Genesys portal at app.signalgenesys.io. If the page asks you to log in, see the Login and Access Issues section below before continuing. 4. Inside Signal Genesys, click the Edit button (pencil icon) at the top of your press release. 5. Scroll to the Distribution Settings section. You will see the Distribution Date and Distribution Time fields. 6. Update both fields to a valid date and time (see the rules below), then click Save. 7. Return to Search Atlas and click Publish again. The error should be resolved. 📋 Rules for a Valid Distribution Date Signal Genesys enforces the following constraints on the Distribution Date. Make sure your selection meets all of them: - Future date and time only: The distribution date must be set to a time that is at least 30 minutes in the future from the moment you save. Dates in the past or within the next 30 minutes will trigger the invalid date error. - Date format: Use the calendar picker inside Signal Genesys rather than typing a date manually. Manual entry can introduce formatting errors that the system does not always flag clearly. - Time zone: The time displayed in Signal Genesys defaults to Eastern Time (ET). If you are in a different time zone, account for the difference when selecting your distribution time so the release does not go out earlier or later than intended. - Business hours recommended: While Signal Genesys accepts any future time, press releases distributed between 8:00 AM and 5:00 PM ET on weekdays reach the widest distribution network. 🔐 Login and Access Issues on app.signalgenesys.io If clicking View in Signal Genesys takes you to a login screen, a blank page, or returns an access error, work through the steps below in order: 1. Check your Signal Genesys credentials: Your Signal Genesys account is separate from your Search Atlas account. Go to app.signalgenesys.io directly in your browser and log in with the email address and password you used when your Signal Genesys account was created. If you are unsure which email was used, check your inbox for a welcome email from Signal Genesys. 2. Reset your password if needed: On the Signal Genesys login page, click Forgot Password and follow the instructions sent to your email. 3. Clear cache and cookies: A cached session from a previous login can block access. Clear your browser cache and cookies, then try opening app.signalgenesys.io again in a fresh tab. 4. Try an incognito or private window: This rules out browser extension conflicts. Open an incognito window, go to app.signalgenesys.io, and log in fresh. 5. Check that your account is linked: Inside Search Atlas, go to Settings → Integrations and confirm that Signal Genesys shows as Connected. If it shows Disconnected or Not configured, click Connect and follow the on-screen steps to re-authorise the integration. Once reconnected, return to your press release and try View in Signal Genesys again. ✅ Quick Checklist Before You Publish Use this checklist each time you are ready to publish a press release to avoid the invalid date error: - Distribution Date is set to a date at least 30 minutes in the future. - Distribution Time is set using the Signal Genesys time picker, not typed manually. - You are logged in to app.signalgenesys.io with your Signal Genesys credentials. - The Signal Genesys integration in Search Atlas Settings shows Connected. - You clicked Save inside Signal Genesys before returning to Search Atlas to publish. 💬 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 SSL Certificate Errors on Landing Page Subdomains

🔍 Overview When you publish a landing page on a custom subdomain (for example, hailstorm.mdmland.com), Search Atlas needs the subdomain's DNS records to be correctly configured before an SSL certificate can be generated. If the DNS records are missing or pointed elsewhere, the certificate will fail to generate and visitors may see a security warning. This article explains what DNS change is required and how to get set up correctly. If you need the specific CNAME target value for your subdomain or guidance on where to find it in your account, please contact our support team as described below. 📋 Prerequisites - Access to your domain registrar or DNS provider (for example, GoDaddy, Cloudflare, Namecheap, or Route 53). - The exact subdomain you entered in Search Atlas when creating your landing page. - The Search Atlas CNAME target value for your landing page — contact our support team if you are unsure where to find this. 🛠️ Step-by-Step DNS Configuration 1. Log in to your DNS provider and navigate to the DNS management section for your root domain (for example, mdmland.com). 2. Create a new CNAME record using the following values: - Type: CNAME - Host / Name: the subdomain prefix only (for example, enter hailstorm, not the full domain) - Value / Points to: the CNAME target provided by Search Atlas for your landing page subdomain - TTL: set to the lowest value your provider allows, for faster propagation 3. Save the record and allow time for DNS propagation to complete. Propagation times vary depending on your DNS provider and your previous TTL settings. 4. Once propagation is complete, Search Atlas should be able to generate the SSL certificate for your subdomain. If the certificate does not appear after propagation, contact our support team with your subdomain name so we can investigate. ✅ How to Confirm Your DNS Is Set Up Correctly Before expecting the certificate to generate, confirm the CNAME record is live. You can use a free tool such as dnschecker.org — enter your full subdomain, select CNAME, and confirm it resolves to the Search Atlas target value. Once the CNAME is resolving correctly, reach out to support if the SSL certificate has not yet been issued. 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 Custom Domain Connection Failures in Website Studio

🔍 Understanding Custom Domain Connection Failures If your custom domain fails to connect to Website Studio even after you've added the correct DNS records, the issue is usually not the DNS records themselves. The most common causes are a proxied DNS toggle that blocks validation and browser cache holding stale data from earlier failed attempts. This article walks you through diagnosing and fixing persistent domain connection errors in Website Studio. ✅ Before You Start: Verify DNS Records Are Correct First, confirm that your DNS records are set up correctly. Log in to your domain registrar (GoDaddy, Namecheap, Route 53, etc.) and check that you've added the CNAME record exactly as Search Atlas provided it. The record should point your subdomain to Website Studio's servers. If your DNS records are correct and the error persists for more than 30 minutes, move to the next section. ⚠️ Step 1: Disable DNS Proxying on Your CNAME Record This is the most common cause of validation failures. Many domain registrars (especially Cloudflare) offer a DNS proxy toggle that encrypts traffic between your domain and their servers. This toggle blocks Website Studio from validating your domain because the validation request cannot reach your actual DNS records. 1. Log in to your domain registrar's dashboard. 2. Find the DNS records section (often under DNS Management or Name Servers). 3. Locate the CNAME record you created for Website Studio. 4. Look for a proxy toggle, often shown as an orange cloud icon (Cloudflare) or similar indicator. It may be labeled "Proxied," "DNS Only," or "Routing." 5. If the toggle is ON (proxied), click it to turn it OFF. 6. Save your changes. After disabling the proxy, Website Studio will be able to validate your domain. Validation typically completes within 5 to 10 minutes, but can take up to 30 minutes. 🗑️ Step 2: Clear Your Browser Cache If you've been testing the domain connection for several hours or days, your browser may be holding cached data from earlier failed validation attempts. This prevents Website Studio from recognizing that the domain is now properly connected. 1. Open Website Studio and navigate to your website settings. 2. Press Ctrl + Shift + Delete (Windows) or Command + Shift + Delete (Mac) to open your browser's cache clearing menu. 3. Set the time range to All Time. 4. Check Cookies and cached images and files. 5. Click Clear data. 6. Close Website Studio completely and reopen it in a fresh browser tab. Return to your domain settings and attempt to validate the connection again. ⏳ Step 3: Wait for DNS Propagation (If Needed) After disabling the proxy toggle, DNS propagation is usually quick. However, some registrars cache changes for up to 48 hours. If validation still fails after 30 minutes, it may be propagation delay. Check your DNS propagation status using a free tool like DNS Checker. Search for "DNS propagation checker," enter your domain, and verify that your CNAME record is live across multiple global DNS servers. If the record shows as live, return to Website Studio and clear your cache again (Step 2). 🛠️ Troubleshooting: Check for Conflicting DNS Records Some domains have multiple CNAME records or A records that conflict with each other. Website Studio requires a dedicated CNAME record pointing only to Website Studio's servers. 1. In your domain registrar's DNS section, list all DNS records. 2. Confirm you have only one CNAME record for the subdomain you're connecting (e.g., www or blog). 3. If you have multiple CNAME records or an A record pointing to the same subdomain, delete the conflicting records and keep only the Website Studio CNAME. 4. Save changes and wait 5 to 10 minutes. 5. Clear your browser cache (Step 2) and retry validation in Website Studio. 🔗 Verify the Connection in Website Studio Once you've completed the steps above, return to Website Studio to verify the domain is now connected. 1. In Website Studio, go to Settings or Domain (exact location depends on your site layout). 2. Look for your custom domain in the domain list. 3. If a green checkmark or "Connected" status appears next to your domain, the connection is successful. 4. If the connection is still pending, wait another 10 minutes and refresh the page. 📋 Common DNS Record Examples Below are typical CNAME records that Website Studio provides. Your specific record may vary, but it will follow this format: - Record Type: CNAME - Name/Subdomain: www (or your chosen subdomain) - Value/Target: [your-site].wsstudio.com (or similar Website Studio domain) - Proxy Status: DNS Only (not proxied) If your registrar shows a different format, refer to their documentation or contact their support. ❌ If Problems Persist If your domain still fails to connect after completing all steps above, there may be a deeper issue with your domain configuration or registrar 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 GoDaddy DNS Propagation Delays in Website Studio

🔍 Overview When you connect an existing GoDaddy domain to a new site in Website Studio, Search Atlas automatically provisions an SSL certificate and waits for your domain's DNS records to propagate across the internet. In most cases this completes within a few hours, but GoDaddy domains can legitimately take 24–48 hours to fully propagate. Seeing a Propagating status after 20 hours is not unusual and does not always indicate an error. ⏱️ Typical Propagation Timeline - 0–6 hours: DNS changes begin spreading to major resolvers worldwide. - 6–24 hours: Most regions resolve correctly; the status banner may still show Propagating. - 24–48 hours: Full global propagation completes. This is the normal outer limit for GoDaddy domains. - Beyond 48 hours: If the domain is still not resolving, a configuration issue is likely. Follow the troubleshooting steps below. ✅ Step 1 — Verify Your DNS Records in GoDaddy Before waiting further, confirm that the correct records were saved in your GoDaddy account. 1. Log in to your GoDaddy account and open My Products → Domains. 2. Click DNS next to your domain. 3. Confirm the following records exist exactly as shown in Website Studio: - An A record pointing to the Search Atlas IP address provided during setup. - A CNAME record for www pointing to your Search Atlas site address. 4. If any record is missing or incorrect, update it and save. Propagation will restart from that point. 🔒 Step 2 — Manually Retry SSL Certificate Provisioning If your DNS records are correct but the domain has been stuck on Propagating for more than 24 hours, the SSL certificate provisioning process may need a manual nudge. Follow these steps inside Website Studio. 1. In the left sidebar, click Website Studio (URL: /website-studio). 2. Locate the site attached to your GoDaddy domain and open its Settings. 3. Navigate to the Domain tab. 4. Find your connected GoDaddy domain. If a Retry SSL or Re-verify Domain button is visible, click it. 5. Wait 5–10 minutes, then refresh the page to check whether the status has updated to Active. 6. If the button is not visible, disconnect the domain and then reconnect it using the same domain name. This resets the SSL provisioning job without changing your DNS records. 🛠️ Step 3 — Check for Common GoDaddy-Specific Issues GoDaddy accounts have a few settings that can silently block propagation. Review each item below. - Domain forwarding is enabled: If GoDaddy is forwarding your domain to another URL, it will override your DNS records. Go to DNS → Forwarding and remove any active forwarding rules. - Domain Privacy & Protection is interfering: In rare cases, GoDaddy's privacy features delay DNS updates. Temporarily disable domain privacy, save, and check propagation again. - TTL is set too high: A very high TTL (e.g., 86400 seconds / 24 hours) on your old DNS records means resolvers cache the outdated values for longer. Lower the TTL to 600 seconds on all relevant records and wait for the cache to clear before expecting the new records to take effect. - Multiple conflicting A records: If GoDaddy shows more than one A record for the same hostname (e.g., two A records for @), delete the outdated one and keep only the Search Atlas IP. 🔎 Step 4 — Check Global Propagation Status Use a free DNS propagation checker (such as whatsmydns.net or dnschecker.org) to see which regions have already resolved your domain to the correct IP address. Enter your domain name, select A record, and look at the results. - If most locations show the correct Search Atlas IP, propagation is nearly complete. Wait a few more hours and retry SSL as described in Step 2. - If most locations still show the old IP or no record, your DNS records in GoDaddy may not have saved correctly. Repeat Step 1. 📋 When to Escalate Contact our support team if any of the following apply after completing all steps above: - It has been more than 48 hours since you last saved the correct DNS records and the domain is still not active. - The Retry SSL button produces an error message. - Disconnecting and reconnecting the domain does not reset the propagation status. - The DNS checker shows the correct IP worldwide but Website Studio still shows Propagating. 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 Website Studio Custom Domain Timeout Errors

🔍 Overview After pointing your domain's A record to Website Studio, you may see an ERR_TIMED_OUT error when visiting your site. This is a common issue and is almost always caused by one of a few configuration gaps — even when DNS propagation appears complete. This article walks you through the most likely causes and the exact steps to fix them. ⚙️ How Custom Domains Work in Website Studio When you connect a custom domain to your Website Studio site, two things must be true at the same time: - Your domain's A record must point to the correct Website Studio IP address. - Website Studio must have your custom domain entered and saved inside the platform so it knows to serve your site when that domain is requested. If either side is missing or mismatched, the connection will time out rather than load your site. ✅ Step 1 — Verify the A Record Is Correct Before troubleshooting inside the platform, confirm your DNS is configured correctly. 1. Log in to your domain registrar or DNS provider (for example, GoDaddy, Namecheap, or Cloudflare). 2. Locate the A record for your root domain (shown as @ or your bare domain name). 3. Confirm the IP address matches exactly what Website Studio provided in its domain setup instructions. Even a single digit difference will cause a timeout. 4. Check that the TTL (Time to Live) is set to 3600 or lower to allow faster propagation. To verify propagation independently, use a tool such as whatsmydns.net and search for your domain's A record. Wait until the majority of global locations show the correct IP before continuing. ⚙️ Step 2 — Confirm the Custom Domain Is Saved in Website Studio DNS propagation alone is not enough. Website Studio must also be configured to recognise your domain. 1. In the left sidebar, click Website Studio and open your project. 2. Go to your site's Settings or Domain section within the builder. 3. Confirm your custom domain (for example, precisionspringfieldcurls.com) is entered exactly as it appears — no trailing slashes, no www prefix unless you also set up a CNAME for www. 4. Save the settings if you make any changes. If the domain field is blank or contains a typo, the platform will not route incoming traffic to your site, which causes a timeout on the visitor's end. 🌐 Step 3 — Check for www vs. Root Domain Mismatch A common source of timeouts is a mismatch between the domain version visitors use and the one configured in DNS. - Root domain (precisionspringfieldcurls.com) requires an A record pointing to Website Studio's IP. - www subdomain (www.precisionspringfieldcurls.com) requires a separate CNAME record pointing to your Website Studio domain handle, or a second A record. If your visitor types www. but you only configured the root A record, the www version will time out. Set up both records if you want both versions to work, and ensure Website Studio has the correct version saved as your custom domain. 🔒 Step 4 — Check for Conflicting DNS Records Conflicting records can silently block traffic even after a correct A record is added. - Look for duplicate A records pointing to different IP addresses for the same hostname. Delete any that do not point to Website Studio's IP. - Check for a CNAME record on the root domain. A root-level CNAME conflicts with an A record and can cause unpredictable timeouts. Remove it if present. - If you use Cloudflare, make sure the proxy (orange cloud) is turned off for the A record. Cloudflare's proxy can intercept traffic and prevent Website Studio from completing its SSL handshake, which causes timeout errors. ⏱️ Step 5 — Wait for Full Propagation and SSL Provisioning Even after everything is configured correctly, you may need to allow additional time. - DNS changes can take up to 48 hours to propagate fully worldwide, though most resolve within 1–4 hours. - Website Studio automatically provisions an SSL certificate once it detects your domain is pointing to it correctly. This process can take up to 30 minutes after propagation completes. - During SSL provisioning, the site may still time out or show a security warning. This is temporary. Try accessing your site in a private or incognito browser window to avoid cached DNS results while you wait. 💡 Quick Troubleshooting Checklist - A record IP matches Website Studio's provided IP exactly. - Custom domain is entered and saved inside Website Studio settings. - No conflicting A records or root-level CNAME records exist. - Cloudflare proxy is disabled for the A record (if using Cloudflare). - www and root domain are both configured if both are needed. - At least 1–4 hours have passed since the DNS change. - Tested in a private browser window to bypass local DNS cache. 🆘 Still Seeing a Timeout? If you have completed every step above and your custom domain is still timing out, our team can inspect your specific domain configuration directly. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Website Studio 404 Errors and Credit Compensation

🔍 What This Article Covers This article explains why 404 errors occur in Website Studio, how to troubleshoot them, and how to request courtesy credits if you used credits while working through a platform issue. ⚠️ Understanding 404 Errors in Website Studio A 404 error in Website Studio means a page or resource could not be found. This can happen for several reasons: - A generated or cloned page was not saved properly before publishing - A project was imported with broken or missing asset links - A temporary platform instability interrupted the page-generation process - A URL path conflict occurred between pages in the same project These errors are usually resolvable without losing your work. Follow the steps below before submitting a compensation request. 🛠️ How to Troubleshoot a 404 Error 1. Navigate to Website Studio: In the left sidebar, click Website Studio. You will land on the /website-studio page. 2. Locate the affected project: Find the project or page showing the 404 error. If the page is missing entirely, check whether it still appears in your project list. 3. Try regenerating the page: Use the Generate PPC Site or Import Site action in Website Studio (What will we get done today?) to recreate the missing page. Clone an existing working page as a base if needed using the Clone an Existing Page option. 4. Check imported projects: If the error appeared after using Import Project, verify that all assets and URLs in the imported files are valid and accessible. 5. Review your Brand Vault: Open Create brand vault to confirm that brand assets are correctly linked, as missing brand assets can sometimes trigger 404 responses during page rendering. 6. Reload and re-publish: After making corrections, save the page and re-publish. Wait one to two minutes, then test the URL again in a fresh browser tab. 💡 Common Fixes That Resolve 404 Errors - Hard refresh the page: Press Ctrl + Shift + R (Windows) or Cmd + Shift + R (Mac) to clear cached data that may be serving the old broken URL. - Check for duplicate slugs: Two pages with identical URL slugs can cause a 404 on one of them. Rename the slug of the affected page to make it unique. - Re-import the project: If an imported project is the source of the error, delete it and re-import using a clean file to rule out file corruption. - Wait for propagation: Newly published pages can take a few minutes to go live. If the 404 is brand new, wait five minutes and check again before troubleshooting further. 📊 When Credits Are Used During a Platform Issue Search Atlas credits are consumed each time a page is generated or a significant action is completed. If a platform-side issue — such as a temporary 404 error during generation — caused a credit to be used without producing a working result, you may be eligible for a courtesy credit refund. To strengthen your request, gather the following information before reaching out: - The date and approximate time the error occurred - The name of the project and the action you were performing (e.g., Generate PPC Site in Website Studio (What will we get done today?)) - The number of credits consumed during the affected session - Any error messages or screenshots you captured 🚀 How to Request Courtesy Credits Credit compensation requests are handled by our support team on a case-by-case basis. To submit a request, follow these steps: 1. Open the Search Atlas platform and log in to your account. 2. Click the chat widget in the bottom-right corner of the platform. 3. Type human teammate to be connected with a member of our team. 4. Provide the details listed in the section above (date, project name, action, credits used, and any error evidence). 5. Our team will review your request and apply courtesy credits to your account if the issue is confirmed to be platform-related. Note: Courtesy credits are granted for verified platform issues, not for user errors such as accidentally generating duplicate pages. Providing clear details speeds up the review process significantly. 🙋 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.

🔒 SSL Certificates and 404 Redirects Explained

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

🔀 Fix 404 Errors and Create Redirects in Website Studio

🔍 Overview If your Site Audit has flagged hundreds of broken URLs, you can export that list, create 301 redirects to send visitors and search engines to the correct pages, and design a custom 404 error page — all within Search Atlas. This article walks you through each step. 📋 Step 1: Export Your 404 URLs from Site Audit Before creating redirects, you need a clean list of all broken URLs on your site. 1. Go to OTTO SEO → Site Audit in the left sidebar. 2. Open your project and wait for the crawl to finish. 3. Navigate to OTTO SEO → Site Audit → Overview (Website Overview) and filter by 404 status code. 4. Click the Export to Docs button to download a CSV file containing all 404 URLs. 5. Open the CSV in a spreadsheet tool. You will see columns for the broken URL and the page that links to it. Use this to determine where each broken URL should redirect. Tip: If you have a large list (such as 915 URLs), sort the broken URLs by folder or pattern. Many URLs may share the same fix, which lets you create fewer redirect rules. 🔀 Step 2: Create 301 Redirects in Website Studio Once you have your list of broken URLs and their intended destinations, set up 301 redirects inside Website Studio. 1. Open Website Studio from the left-hand navigation. 2. Select the project that matches the site you audited. 3. Go to Settings inside your project, then find the Redirects section. 4. Click Add Redirect. 5. In the Source field, enter the broken URL path (for example, /old-page-name). 6. In the Destination field, enter the new URL path where you want visitors to land (for example, /new-page-name). 7. Set the redirect type to 301 (Permanent). 8. Click Save. 9. Repeat for each URL in your export list, or use bulk import if that option is available in your plan. Note: A 301 redirect tells search engines that the page has permanently moved. This passes link equity to the new URL and removes the broken URL from search results over time. 🎨 Step 3: Create a Custom 404 Error Page in Website Studio Even after setting up redirects, some visitors may still reach a dead end. A well-designed custom 404 page improves the user experience and keeps visitors on your site. 1. Inside your Website Studio project, click Add Page. 2. Name the page 404 or Page Not Found. 3. Use the drag-and-drop editor to design the page. Best practices include: - A clear, friendly message explaining the page does not exist. - A search bar or navigation links to help visitors find what they need. - A prominent button linking back to your homepage. 4. Once the page is designed, go to Settings for the page and assign it as your site's 404 error page. 5. Save and publish your changes. Tip: Keep the message short and helpful. Avoid technical language — a simple line like "Sorry, we can't find that page. Let's get you back on track." works well. ✅ Step 4: Verify Your Redirects Are Working After setting up your redirects and custom 404 page, confirm everything is functioning correctly. - Paste a formerly broken URL into your browser and confirm it lands on the correct destination page. - Re-run a Site Audit crawl after a few days to verify the 404 errors are no longer flagged. - Check that your custom 404 page appears when you visit a URL that genuinely does not exist on your site. ❓ Frequently Asked Questions Can I bulk-import redirects instead of adding them one by one? Bulk import availability depends on your plan. Check the Redirects section in Website Studio settings for an import option. If you do not see one, adding redirects individually or grouping similar URL patterns into wildcard rules can save time. Should I use a 301 or 302 redirect? Use a 301 (Permanent) redirect when a page has moved for good. Use a 302 (Temporary) redirect only when the move is short-term, such as during a promotion or A/B test. For fixing 404 errors, 301 is almost always the right choice. Why are 404 errors bad for SEO? Broken pages waste crawl budget, lose any backlink value pointing to them, and create a poor experience for visitors. Fixing them with 301 redirects transfers authority to your live pages and improves overall site health. 💬 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 Custom JavaScript Not Appearing After Publishing

🔍 Overview If you have added custom JavaScript code to your Search Atlas site but it is not appearing in your live site's source, follow the steps below to troubleshoot the issue yourself. If the steps do not resolve it, the final section explains what to have ready when escalating to support. 🧰 Troubleshooting Steps to Try First 1. Confirm you saved and published after adding the code. Adding code to the platform does not automatically update your live site. After pasting your JavaScript snippet, save your changes and then click Publish to push the update to your live site. 2. Check that you added the code in the correct location. Search Atlas supports custom code injection at both the site level (applies to all pages) and the individual page level. Verify you placed the snippet in the intended location — a snippet added only to one page will not appear on others. 3. Clear your browser cache and hard-reload the page. Browsers cache page sources aggressively. After publishing, perform a hard refresh (Ctrl+Shift+R on Windows/Linux, Cmd+Shift+R on Mac) or open the page in an Incognito/Private window before checking View Page Source. 4. Verify your plan includes custom code features. Access to custom JavaScript injection may depend on your current Search Atlas subscription plan. Check your plan details in your account settings to confirm this feature is available to you. 5. Check for syntax errors in your snippet. A JavaScript snippet with a syntax error may be stripped or fail silently. Review your code for unclosed brackets, missing semicolons, or other syntax issues before re-saving. 6. Re-save and re-publish. If the above steps do not resolve the issue, remove the snippet, save, publish, then re-add the snippet, save, and publish again to force a fresh injection. 📋 What to Have Ready If You Need to Escalate If the steps above do not resolve the issue, please have the following information ready when you contact support: - The exact location in the platform where you added the JavaScript (e.g., which menu or settings panel you used) - The project or site name where the code was added - The URL of the specific page where the code should appear - Whether you published the site after adding the code, and approximately when - The full JavaScript snippet you are trying to inject (or a description of what it does) - Any error messages or unexpected behavior you observed - A screenshot of your browser's page source (right-click → View Page Source) showing that the code is absent 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 Custom Domain SSL Stuck on Pending

🧭 Overview When you connect a custom domain in Website Studio, Search Atlas automatically provisions an SSL certificate for your site. In most cases this completes within minutes. If the status stays on Pending and your site won't load, the most common cause is an AAAA (IPv6) record on your domain that conflicts with SSL provisioning. This article walks you through diagnosing and fixing that conflict, and clarifies the differences between the setup instructions you may have seen. ⚠️ Why SSL Gets Stuck on Pending Search Atlas provisions SSL over IPv4. If your domain has an AAAA record (which points to an IPv6 address), your browser or DNS resolver may route requests over IPv6 instead. Because our SSL certificate provisioning service does not respond on that IPv6 path, the verification handshake never completes and the certificate stays in a Pending state indefinitely. The domain appears broken even though every other setting looks correct. 🔍 Step 1 — Check for an AAAA Record 1. Go to your domain registrar or DNS provider (for example, Cloudflare, GoDaddy, Namecheap, or Route 53). 2. Open the DNS Management or DNS Records section for your domain. 3. Look for any record with Type = AAAA. It may be set to your root domain (@) or a subdomain such as www. 4. If you find one or more AAAA records, continue to Step 2. If you find none, skip to Step 4. 🗑️ Step 2 — Remove the AAAA Record 1. Select the AAAA record in your DNS provider's dashboard. 2. Delete it. If your provider asks for confirmation, confirm the deletion. 3. Repeat for every AAAA record associated with the domain or subdomain you are connecting to Website Studio. 4. Do not delete A records, CNAME records, or TXT records — only AAAA records. Note: Removing an AAAA record does not break your domain. It simply stops IPv6 routing, which is not required for Search Atlas to serve your site. ⏳ Step 3 — Wait for DNS Propagation and SSL Renewal 1. DNS changes can take 5 minutes to 48 hours to propagate worldwide, depending on your provider and your domain's TTL (Time To Live) setting. 2. After removing the AAAA record, return to Website Studio → Settings → Custom Domain. 3. If the SSL status still shows Pending, click Retry SSL (or disconnect and reconnect the domain) to trigger a fresh provisioning attempt. 4. Monitor the status. It should move to Active within a few minutes once DNS has propagated. ✅ Step 4 — Verify Your Required DNS Records Whether or not you had an AAAA record, confirm that your DNS settings exactly match the following. These are the authoritative values for Website Studio: - A record — Point your root domain (@) to the IP address shown in Website Studio → Settings → Custom Domain. - CNAME record — Point www to the target hostname shown on the same settings screen (for example, sites.searchatlas.com). - No AAAA records on the root domain or www subdomain. Use a free tool such as dnschecker.org or mxtoolbox.com to confirm your records have propagated before retrying SSL. 📋 A Note on Contradictory Setup Instructions You may have noticed differences between the setup steps described in our help documentation and the instructions shown by the in-app setup assistant. Here is what each source is intended for: - In-app setup assistant (the guided flow inside Website Studio) — These steps are the current, correct instructions. Always follow these when connecting a domain for the first time. They reflect the latest infrastructure configuration. - Help Centre articles published before mid-2024 — Some older articles referenced a legacy CNAME-only setup that has since been updated. If an article tells you to point @ to a CNAME target rather than an A record, that article is outdated. Follow the in-app instructions instead. We are actively auditing and updating older documentation to remove this inconsistency. We apologise for any confusion this has caused. 🛠️ Quick Troubleshooting Checklist - AAAA record removed from DNS? Yes / Not applicable - A record for @ pointing to the correct IP? Yes - CNAME for www pointing to the correct target? Yes - DNS propagation confirmed via dnschecker.org? Yes - SSL Retry triggered in Website Studio after DNS update? Yes - Waited at least 15 minutes after retrying? Yes If all items above are checked and SSL is still showing Pending after 2 hours, escalate using the contact method below. 💬 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 an Incorrect Shopify Store Connection in Publish

Overview If the wrong Shopify store is showing in your Publish menu — for example, you see dahingplants.com but need grandeplants.com — this means a different store was connected at some point during setup. This article explains why this happens and how to get it resolved quickly. Why the Wrong Store Appears This usually happens for one of the following reasons: - A different Shopify account was logged in when the connection was first authorised. - The OAuth authorisation flow was completed on the wrong store's admin page. - Multiple Shopify stores exist under related accounts and the wrong one was selected during setup. The good news is this is fully reversible — the incorrect store can be disconnected and the correct one reconnected. How to Fix a Wrong Shopify Store Connection Because the exact steps for disconnecting and reconnecting a Shopify store in the Publish menu depend on your specific account configuration, a member of our support team will need to walk you through the process or make the change on your behalf. To get this resolved as quickly as possible, please have the following information ready before reaching out: - Your Search Atlas project name - The incorrect store domain currently showing in the Publish menu (e.g., dahingplants.com) - The correct store domain you want to connect (e.g., grandeplants.com) - A screenshot of the Publish menu showing the wrong store, if possible Having these details ready will allow a teammate to identify your account immediately and action the store switch without delay. 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 Website Studio Spinning Wheel and Publishing Failures

🔍 Overview Some customers encounter a spinning wheel, red alert banners, or a stuck publishing state inside Website Studio. In some cases, content added to one page disappears or strips content from other pages. These issues are typically caused by a jammed UI session, a cached publishing state, or a temporary sync error between the editor and the backend. This article walks you through the steps to resolve these issues quickly. ⚠️ Common Symptoms - A spinning wheel appears during site generation or content publishing and never completes. - Red alert banners display after attempting to publish a page or blog post. - Content added to a page does not save, or saving one page removes content from another. - The Website Studio UI becomes unresponsive or appears frozen. - A published post shows a placeholder title or slug instead of the one you entered. 🛠️ Step-by-Step Fixes 1. Hard-refresh the page. Press Ctrl + Shift + R (Windows/Linux) or Cmd + Shift + R (Mac) to force a full reload and clear any cached UI state. Do not use the browser's back button, as this can preserve the jammed state. 2. Clear your browser cache and cookies. Go to your browser settings, clear cached images, files, and cookies for the Search Atlas domain, then reload Website Studio at Left sidebar → Website Studio. 3. Try a different browser or incognito window. Open an incognito or private window (or switch to Chrome, Firefox, or Edge) to rule out browser extensions or local cache as the cause. 4. Wait two to three minutes before retrying. If a publishing job is stuck in a pending state on the server, forcing another publish immediately can create a conflict. Wait a short time, then attempt to publish again. 5. Re-enter content on the affected page. If content was stripped from a page after saving another, re-enter the missing content, save that page first, then proceed to publish. Avoid editing multiple pages simultaneously in separate tabs. 6. Verify the page title and slug before publishing. A known issue can cause posts to publish with a placeholder title or slug. Always confirm the title and slug fields are correctly filled in the editor before clicking publish. 7. Re-generate the affected page. If the page remains broken after the steps above, use the Generate PPC Landing Page, Clone an Existing Page, or Build a Local Website options from Website Studio to recreate the page from scratch. ✅ How to Avoid This Issue Going Forward - Edit and publish one page at a time rather than working across multiple tabs. - Always confirm the page title and slug fields are populated before publishing. - Keep your browser updated to the latest version for the best compatibility with Website Studio. - Save your content frequently using the in-editor save option before triggering a full publish. - If you notice a spinning wheel lasting more than 60 seconds, refresh immediately rather than clicking publish again. 💬 Still Need Help? If the spinning wheel or publishing failure persists after following all the steps above, our team can investigate the specific session or publishing job on your account. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Website Studio Publishing and Display Issues

🔍 Overview Website Studio issues typically fall into four categories: publishing getting stuck on the Almost ready screen, formatting changes appearing unexpectedly during edits, hero image links breaking after an update, and projects becoming temporarily inaccessible. This article walks you through the most effective fixes for each. ⏳ Publishing Hangs on 'Almost Ready' If your site stays on the Almost ready screen for more than a few minutes, the publishing process may have stalled. Follow these steps to resolve it: 1. Wait at least 3–5 minutes before taking action — some publish jobs take longer depending on page complexity. 2. Refresh the page. Navigate to Left sidebar → Website Studio (URL: /website-studio) and reopen your project. 3. Check whether the site has actually published by opening the live URL in a new browser tab. The publishing job sometimes completes in the background even when the screen appears frozen. 4. If the project still shows as stuck, close the project, return to the Website Studio dashboard, and attempt to publish again from the project card menu. 5. Clear your browser cache or try a different browser to rule out a local caching issue. This issue is a known platform behaviour that has been addressed in recent updates. If repeated publish attempts fail, contact support using the instructions at the bottom of this article. 🎨 Unexpected Formatting Changes During Edits You may notice that layout, font, spacing, or colour changes appear inconsistently — or that the editor reports a successful change that is not reflected in the preview. This is a known visual sync issue. Here is how to handle it: 1. After making a change, wait 10–15 seconds and then manually refresh the preview panel rather than assuming the change failed. 2. If the preview still does not update, save your work, exit the project, and reopen it. The editor re-syncs on reload. 3. Avoid making rapid successive edits before the previous change has confirmed. Submit one change at a time and wait for confirmation before proceeding. 4. If you are using AI agent-requested changes, add clear, specific instructions and include reference images where possible. Vague prompts are more likely to produce inconsistent results. 5. After publishing, verify changes on the live URL — not just the in-editor preview — to confirm the final output. 🖼️ Hero Image Links Break After Updates Hero image links can break when a page update regenerates asset paths or overwrites manually set link targets. To prevent and fix this: 1. After any publish or major edit, check all hero image links by previewing the live page and clicking each linked image. 2. If a link is broken, re-enter the destination URL directly in the image link field within the editor and save the change explicitly before publishing again. 3. Avoid navigating away from the editor immediately after setting an image link — confirm the field has saved by seeing the URL persist in the input. 4. If the same image link breaks repeatedly after updates, try unlinking and relinking the image from scratch rather than editing the existing link value. 🚫 Unable to Access a Project If a project appears missing or you cannot open it from the Website Studio dashboard, try the following: 1. Refresh the Website Studio page at Left sidebar → Website Studio (/website-studio). 2. Log out and log back in to reset your session. 3. Check with your account administrator that your team role has the correct permissions. Admins can review this under Top-right corner (avatar) → Team Members → Team Members. 4. Try a different browser or an incognito window to rule out extension or cache conflicts. ✅ Quick Reference Checklist - Stuck publishing: Refresh, check live URL, retry publish, clear cache. - Formatting not saving: Wait for confirmation, reload editor, make one change at a time. - Broken image links: Re-enter and save the link explicitly after each publish. - Project inaccessible: Refresh, log out and in, verify team permissions. 💬 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 Domain Blocked by Old DNS Records

🔍 What Is Causing This Error? When you try to connect a registered domain to Search Atlas and receive an error indicating that the domain is already in use or cannot be connected, the most common cause is a leftover DNS record from a previous Website Studio project. Even if that project has been deleted or is no longer active, its DNS entry can remain and block any new domain connection attempts. This is not an issue with your domain registrar or your DNS provider. The conflict exists inside Search Atlas, where an old Website Studio record is still associated with that domain. ⚠️ How to Confirm This Is Your Issue You are likely experiencing this problem if all of the following are true: - Your domain is fully registered and active with your domain registrar. - You are attempting to connect the domain inside Search Atlas and receive an error indicating the domain is already claimed or in use. - You do not see any active project in Website Studio currently using that domain. - The domain was previously used in a Website Studio project that has since been removed or is no longer active. 🛠️ What to Do Because this conflict involves an internal DNS record that may have been orphaned when a previous Website Studio project was deleted, it typically cannot be resolved through self-serve steps alone. The Search Atlas support team will need to manually remove the conflicting record on your behalf. To help the team resolve this as quickly as possible, please have the following ready before reaching out: - The exact domain name that is blocked (e.g., example.com). - The name of any Website Studio project you believe previously used this domain, if known. - The error message text you are seeing when attempting to connect the domain. - The date and approximate time you first encountered the error. - Your Search Atlas workspace name or account email. 🧹 Why Orphaned DNS Records Happen An orphaned DNS record is created when a Website Studio project is removed without first disconnecting the custom domain assignment. Search Atlas retains the DNS mapping as a safeguard, but this can prevent you from reusing or reassigning the domain later. ✅ How to Prevent This in the Future - Before deleting any Website Studio project, always disconnect your custom domain from the project first, then proceed with deleting the project. - Confirm the domain no longer shows as connected before completing the deletion. 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 SSL and Multi-Domain Setup in Webstudio

🔍 Overview When you publish a landing page in Search Atlas's Webstudio, connecting a custom domain and provisioning an SSL certificate requires coordination between your DNS provider and Webstudio's backend. If your site shows Not Secure, or if you are trying to host multiple landing pages under a single domain, this article explains what to expect and how to get the right help. ⚙️ What Happens During Domain and SSL Setup After you enter a custom domain in Webstudio's Publish settings, Webstudio attempts to provision an SSL certificate automatically once your DNS records are pointed correctly. SSL provisioning is a backend process — it runs on Webstudio's infrastructure and is not something you can trigger manually from within the platform UI. Common reasons a site may continue to display Not Secure include: - DNS records that have not yet propagated to all nameservers. - A mismatch between the domain entered in Webstudio and the domain configured at your DNS provider. - DNS configuration issues that prevent the SSL provisioning process from completing successfully. 🛠️ What to Prepare Before Contacting Support Because SSL provisioning and multi-domain configurations are resolved by our team on the backend, please have the following information ready when you reach out: - Your Webstudio project name — so the team can locate your specific project. - The exact custom domain you entered in Webstudio's Publish settings (e.g., landing.yourdomain.com). - Your DNS provider or domain registrar name (e.g., Cloudflare, GoDaddy, Namecheap). - A screenshot or description of the error — for example, the exact browser warning or the status shown in Webstudio after publishing. - How long ago you made the DNS changes — DNS propagation takes time, and this helps the team assess whether provisioning is still in progress or has stalled. - Whether you are trying to connect multiple landing pages to one domain, and if so, how many pages and what the intended URL structure is. ℹ️ What to Expect Our team will review your project's domain and SSL status on the backend and work with you to resolve the configuration. You do not need to attempt further changes to your DNS or Webstudio settings before speaking with support, as additional edits during an active provisioning attempt may cause further delays. 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 Website Studio Publishing Failure No Target Element

What Is This Error? When you publish a project in Website Studio and the live site appears blank — even though the preview looks correct — the underlying cause is usually a "no target element specified" error. This is a build-time failure that prevents the page from rendering correctly in a browser. It can affect any device and will not resolve itself with a simple refresh. This error requires investigation and correction by the Search Atlas support team on the backend. This article explains what to expect and what information to have ready when you reach out. Why This Happens The error occurs when the publishing build process encounters a failure that prevents your page content from rendering on the live URL. The preview environment loads content differently from the live build, which is why the page can appear correct in preview but fail entirely once published. Because this is a build-level failure, it cannot be resolved by refreshing the page or republishing without backend intervention. What to Expect Once you contact support, a member of our team will investigate the build error associated with your project on the backend. Resolution typically involves correcting the broken build state so your project can be published successfully. You do not need to delete your project or recreate your content. What to Have Ready When You Escalate To help our team resolve this as quickly as possible, please have the following information available before reaching out: - The exact name of the affected Website Studio project - The published URL that is appearing blank - The approximate date and time you first noticed the blank live site - Any error message text you can see, copied exactly as displayed - A note on whether the preview still appears correct or is also affected 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 Website Studio 404 Errors and Loading Failures

🔍 Overview If your Website Studio projects are not loading in the editor, or if pages on your published site are returning a 404 "page does not exist" error, our team is aware of these issues and is working to investigate them. This article explains what to do and what information to have ready when contacting support. ⚠️ Common Symptoms - Projects fail to open in the Website Studio editor. - Published pages return a 404 error. - Newly published pages do not display correctly after publishing. - Client projects do not load inside the project editor. 🧠 Why This Happens Website Studio 404 errors and project loading failures are known issues that may affect some users. Because these issues occur at the platform level, they typically cannot be resolved through account-side changes alone and require investigation by our support team. 🛠️ What to Do 1. Note the details of the issue. Before contacting support, gather the following information so our team can investigate as quickly as possible: - The name of the affected project or projects. - The exact error message you are seeing (e.g., the full 404 error text). - The URL or URLs of the affected pages. - The approximate date and time when the issue started. - Whether the issue affects one project or multiple projects. 2. Do not make additional changes to the affected projects while the issue is ongoing, as this may complicate investigation. 3. Contact our support team with the information above so we can look into the root cause and apply the appropriate fix on our end. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🌐 Fix Website Studio Domain Mismatch and Form Duplication

🔍 Overview When your Website Studio project is published or shared, issues can arise if your primary domain and published domain do not match. Symptoms may include the social share thumbnail displaying the wrong domain, live site errors, or duplicate form submissions. This article explains what to check and how to get this resolved. ⚠️ Understanding the Root Cause Website Studio relies on the domain configured in your project to generate social share metadata, rewrite internal URLs, and route form submissions correctly. When the domain recorded in your project does not match the domain your site is actually live on, one or more of these systems can fail: - Thumbnail mismatch: Social platforms may cache and display an incorrect preview if the metadata points to the wrong domain. - URL forwarding or server errors: Internal links and redirects may break or produce errors if they are resolved against a mismatched domain. - Form submission duplication: Form submissions may be posted more than once if endpoints are resolving against both an old and a new domain during a transition. 🛠️ What to Check If you are experiencing any of the symptoms above, the most important thing to verify is that the domain configured inside your Website Studio project exactly matches the domain your site is published and live on. A mismatch between these two — even a difference as small as a missing or extra subdomain prefix — is the most common cause of all three symptoms. You should also check whether any domain forwarding or redirect rules set up outside of Search Atlas (for example, at your registrar or DNS provider) are pointing to the correct domain. An external forwarding rule that points to a different domain than the one recorded in your project can create redirect loops or server errors even after you correct the project settings. 📋 What to Have Ready When You Contact Support Because confirming and correcting a domain configuration in Website Studio requires access to your specific project settings, our support team will need to look into this on your behalf. To help us resolve this as quickly as possible, please have the following information ready: - The name of the Website Studio project affected - The domain your site is intended to be live on (the correct domain) - The domain currently appearing in the wrong location (e.g., in the social share thumbnail URL or in error messages) - Any exact error messages or HTTP error codes you are seeing - The timestamp of when you first noticed the issue 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.

🔌 Publish Content via API to Your Loveable Site

Overview Search Atlas supports publishing content directly to your Loveable site via an API connection. This allows you to push AI-generated articles and optimized pages from Search Atlas straight to your live site without manually copying and pasting content. How to Publish Content to Your Loveable Site via API Loveable is a no-code website builder. Publishing content from Search Atlas to a Loveable site via API requires a specific configuration that depends on your Loveable project's setup. Because the exact steps vary based on how your Loveable project is configured, our support team can walk you through the process directly. To get the fastest resolution, please have the following ready before reaching out: - Your Loveable project name or URL - The type of backend connected to your Loveable project (if any) - Any API credentials or keys you have already generated for your project - A description of what you have tried so far and any error messages you have seen (including exact error text and timestamps) Troubleshooting Common Issues - Authentication errors: Double-check that your API key or access token is entered correctly and has not expired in your backend service. - Content not appearing: Verify that your Loveable project's backend is active and that the correct endpoint URL was used. - Publish attempt fails with no error: Note the exact timestamp of the failed attempt and any error codes shown, as this information will help our team diagnose the issue quickly. 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 'Domain Already Registered' Error in Website Studio

🔍 What This Error Means When you try to connect a custom domain (for example, expressbailbonds.com) to a new Website Studio project, you may see a "Domain already registered" error. This typically happens when the domain was previously connected to another project that has since been deleted. Even after the old project is removed, the domain can remain linked in the background — an orphaned record — which blocks you from using it again. Follow the steps below to try to resolve this before contacting support. ⚙️ Step 1: Remove the Domain From Any Existing Project Before connecting your domain to a new project, check whether it is still assigned to an older or inactive project. 1. Go to Left sidebar → Website Studio. 2. Open each existing project and look for domain or settings options. 3. If your domain appears linked to a project you no longer need, navigate to that project's settings and remove or replace the domain there. 4. Save your changes before moving on. If you do not see the domain attached to any active project, the record may be orphaned and invisible to you — skip to Step 3. 🚀 Step 2: Reconnect the Domain to Your New Project Once you have removed the domain from the old project, try adding it to your new project. 1. In Left sidebar → Website Studio, open the project you want to use as your new website. 2. Navigate to that project's settings or domain configuration area. 3. Enter your custom domain and save. If the error is gone, your domain is now successfully connected. If the "Domain already registered" error still appears after completing Step 1, proceed to Step 3. 💡 Step 3: If the Error Persists — Contact Support In some cases, the domain record is stored at a deeper system level and cannot be cleared by the steps above. This is the orphaned-record scenario. If you still see the error after following Steps 1 and 2: - The issue is not caused by anything on your end. - A support teammate can investigate and manually remove the orphaned record on your behalf. 🛠️ When to Contact Support Reach out if: - The error appears even though the domain is not attached to any visible project. - You removed the domain from an old project but the error persists after trying again. - You are unable to locate a settings or domain area inside your project. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected to our support team.

📋 Restore Removed Articles to Publisher Queue

🔍 Overview Articles in your publisher queue can sometimes be removed before you have had a chance to publish them. This article explains the most common reasons this happens and walks you through the steps to get your articles reassigned so you can continue publishing without delay. ❓ Why Are Articles Removed From the Queue? There are several reasons an article may be removed from your publisher queue before you publish it: - Inactivity or expiration: Articles that sit in a queue without action for an extended period may be automatically recycled and reassigned to another publisher. - Publisher rejection handling: If an article was flagged or rejected at any point in the pipeline, the system may remove it and route it for review or regeneration. - Pipeline maintenance: Occasional system improvements to the article pipeline can affect queue assignments, particularly during infrastructure updates. - Admin or team action: A team member with admin permissions may have unassigned or removed the article manually. Regardless of the cause, our support team can locate your articles by their reference numbers and reassign them to your queue. 🛠️ What to Do If Your Articles Were Removed If you notice that articles have disappeared from your publisher queue, follow these steps: 1. Collect your article reference numbers. Note down the ID numbers of the missing articles (for example, #200101–#200105, #200107). These make it much faster for our team to locate and restore them. 2. Check your Content Genius library. Go to Left sidebar → Content → Content Genius. Your articles may still exist in draft or completed status even if they are no longer visible in the publisher queue. 3. Check with your team. If you share the account, go to Top-right corner (avatar) → Team Members to see whether an admin on your team made changes to the queue assignments. 4. Contact support with your article IDs. If the articles are not visible anywhere, reach out to our team immediately with your reference numbers so we can restore them as quickly as possible. ⚡ How to Speed Up the Restoration Process To help our team resolve your request as fast as possible, have the following information ready before you contact support: - The article reference numbers (e.g. #200101, #200102) - The approximate date you last saw the articles in your queue - The website or domain you intended to publish them on - Whether any team members have admin access who may have made changes The more detail you provide upfront, the quicker our team can locate and reassign your articles. 🚫 How to Prevent Articles From Being Removed To reduce the risk of losing articles from your queue in the future, keep these best practices in mind: - Publish or schedule articles promptly. Once an article is assigned to your queue, aim to publish or schedule it as soon as possible to avoid automatic recycling. - Monitor your queue regularly. Check your publisher queue at least a few times per week so you can catch any unexpected changes early. - Communicate with your team. If multiple team members have admin access, make sure everyone knows which articles are actively being worked on to prevent accidental removal. - Note your article IDs. Keep a simple record of article reference numbers for any piece you are actively preparing to publish. This makes recovery much faster if something goes wrong. 💬 Need Further Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix WordPress Plugin Blog Post Publishing Errors

🔍 Overview Some users encounter errors when attempting to publish or sync a blog post through the Search Atlas WordPress plugin. Common symptoms include a generic publish failure message, an HTTP 400 error, or a prompt asking for an application password that does not appear in your settings. This article explains what causes these issues and what steps to take. ❓ Do You Need an Application Password? No. As of plugin version 2.6.10, the Search Atlas WordPress plugin uses its own API key for authentication. You do not need to set up a WordPress application password. If you see guidance elsewhere suggesting this step, it does not apply to the current version of the plugin. You can safely ignore any prompts or instructions related to application passwords. ✅ Step 1: Confirm Your Plugin Is Connected Before investigating further, verify that your WordPress site is properly connected to Search Atlas: 1. Log in to your Search Atlas account. 2. Navigate to Account Menu → Settings → CMS Connectors. 3. Confirm that your site appears as connected and that the connection status shows no errors. 4. If the site is not connected, disconnect and reconnect it to refresh the authentication. ⚙️ Step 2: Check Your Plugin Version Make sure you are running the latest version of the Search Atlas WordPress plugin. An outdated plugin version can cause compatibility issues with the publishing pipeline. 1. Log in to your WordPress admin dashboard. 2. Go to Plugins → Installed Plugins. 3. Locate the Search Atlas plugin and check the version number. 4. If an update is available, apply it immediately and then retry publishing. 🔄 Step 3: Retry Publishing the Article After confirming the connection and plugin version, attempt to publish or sync your blog post again. In some cases, a temporary failure in the publishing pipeline can resolve itself after a reconnection or plugin update. 1. Open your article inside Content Genius by going to Left sidebar → Content → Content Genius. 2. Select the article you want to publish. 3. Attempt to publish or sync it to your connected WordPress site. 4. If the error persists, note the exact error message displayed — this will be important for the support team. ⚠️ When the Error Is a Known Bug In some cases, a publishing failure is caused by an issue on the Search Atlas side — specifically a pipeline error that prevents the API key from being recognised correctly during the publish request. This is a known bug that the engineering team has actively worked to resolve. If you have completed all the steps above and the error still occurs, this is likely a platform-level issue rather than a configuration problem on your end. You have not done anything wrong. The most effective next step is to contact our support team so they can investigate your specific account and connected site. 🚫 Common Errors This Article Covers - Could not publish to WordPress page - Unable to publish blog post (rest_forbidden error) - Unable to save content as a draft to a connected WordPress account - Empty response from the WordPress publish endpoint - HTTP 400 INVALID_ARGUMENT error related to the publishing pipeline 💬 Contact Support If you have followed all the steps above and are still unable to publish your blog post, our team can investigate the issue directly on your account. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team. When reaching out, please share the following to help us resolve your issue faster: - The exact error message you are seeing - Your WordPress site URL - The version of the Search Atlas WordPress plugin you have installed - The article title or URL you were trying to publish

🔐 Fix SSL Certificate Failures for Custom Domains

🧩 What This Article Covers When connecting a custom domain in Website Studio, the DNS verification step may pass successfully — but the SSL certificate generation then fails repeatedly. This article explains why that happens and how to fix it so your domain loads securely over HTTPS. ⚠️ What Causes This Issue SSL provisioning failure after a successful DNS check is almost always caused by an incorrectly configured DNS record — specifically an A record or AAAA record that is pointing to the wrong address. Even though the basic DNS lookup resolves, the SSL certificate authority cannot complete verification when the underlying record is misconfigured. Common signs you are experiencing this issue: - The DNS check in Website Studio shows a passing status. - The SSL certificate status shows generating for an extended period, then fails. - The failure repeats every time you attempt to re-provision the certificate. - Your custom domain does not load over HTTPS after publishing. 🛠️ How to Fix It 1. Log in to your domain registrar or DNS provider (for example, GoDaddy, Cloudflare, Namecheap, or wherever your domain's DNS is managed). 2. Locate your DNS records for the custom subdomain or root domain you are connecting to Website Studio. 3. Check your A record and AAAA record values carefully. An A record must point to a valid IPv4 address, and an AAAA record must point to a valid IPv6 address. A common cause of SSL failure is an AAAA record set to an incorrect or placeholder value, or an A record pointing to the wrong IP address. 4. Correct any misconfigured records. If you are unsure what IP address values to use, refer to the DNS setup instructions shown inside Website Studio when you added the custom domain, or contact your DNS provider for guidance on the correct values. 5. Save your changes in your DNS provider's dashboard and allow time for propagation — this can take anywhere from a few minutes to up to 48 hours depending on your provider and TTL settings. 6. Return to Website Studio and attempt to connect or re-provision the custom domain again once DNS propagation is complete. ✅ How to Confirm the Fix Worked After updating your DNS records and re-attempting provisioning in Website Studio, the SSL certificate status should move from generating to a confirmed active or connected state. You can verify the fix by opening your custom domain in a browser and confirming that a padlock icon appears in the address bar, indicating a secure HTTPS connection is active. 💡 Tips to Avoid This Issue in the Future - Double-check every DNS record value before attempting to connect a custom domain — pay close attention to A records and AAAA records. - If you have an AAAA record configured but your hosting does not use IPv6, consider removing the AAAA record entirely rather than leaving it set to an incorrect value. - Use a free DNS lookup tool (such as MXToolbox or Google Admin Toolbox) to verify what your records resolve to before re-attempting SSL provisioning. - Allow full DNS propagation before retrying — attempting to provision the certificate too early can cause repeated failures even after a correct DNS change. 💬 Still Need Help? If you have corrected your DNS records and SSL provisioning is still failing, 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.

🛠️ Resolving WordPress Publishing and Vault Errors

🔍 Understanding the Error If you are seeing a REST API sync failure or a "Brand Vault not connected" error while using Content Genius, these are known issues that our engineering team is actively investigating. These errors can prevent content from being published to WordPress and may affect access to your saved brand guidelines. ⚙️ What to Gather Before Reaching Out To help our team diagnose and resolve these errors efficiently, please have the following information ready: - The exact error message you are seeing, including any error codes. - The URL of your WordPress site. - A screenshot of the error or the affected screen. - The date and approximate time the error occurred. - Whether the issue happens every time or only intermittently. 💡 Known Impact These issues may affect your ability to publish articles directly from Content Genius to WordPress, or may prevent Content Genius from accessing your Brand Vault settings. Our team is working to identify the root cause and deploy a fix as quickly as possible. 💬 Need Additional Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Wix Content Genius Publish and Sync Defects

🔍 Overview When you publish content from Content Genius to a Wix-connected site, you may notice rendering issues that affect how your page appears in search results and on the live site. This article explains what is known about these defects and what to expect while our team works on a resolution. ⚠️ Known Issues Affecting Wix Integrations Our engineering team has confirmed defects related to how Content Genius syncs post content to Wix, specifically affecting how titles, headings, and image metadata are rendered after publishing. The affected areas include post-render title output and image metadata such as the featured image and associated metadata fields. These issues are actively tracked in our development backlog and are being worked on in priority order. ✅ What You Can Do Right Now Because these defects occur at the platform integration level, there is no self-serve fix that fully resolves the underlying sync behavior. However, you can take the following steps to mitigate the impact while a fix is in progress: - After syncing from Content Genius, manually review the affected post directly in your Wix site editor and check that headings, titles, and image metadata appear as expected. - If you notice incorrect values, manually update those fields within Wix to reflect your intended content until the sync defect is resolved at the platform level. - Note the specific post URL, the exact fields affected, and any error messages or unexpected output you observe, so you can share these details if escalation is needed. 📋 When Contacting Support To help our team investigate and prioritize your case, please have the following ready: - Your project or site name in Search Atlas - The URL of the affected Wix page or post - A description of which fields are incorrect (e.g. title, heading structure, featured image, metadata) - Any screenshots showing the issue on the live page If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🌐 Verify Your Publishing Destination Before Going Live

🎯 What This Article Covers When you publish a new site or landing page through Website Studio to a newly purchased domain, it is natural to want confirmation that your original website will not be affected. This article explains how to review and verify your publishing destination before anything goes live, so you can publish with confidence. 🏗️ How Website Studio Publishing Works Every site you build in Website Studio is tied to a specific publishing destination. That destination is determined by the domain you connect during the setup process. Search Atlas does not automatically overwrite or redirect any existing website — your original site remains completely untouched unless you explicitly point its domain to a new Website Studio project. Key points to understand: - Each Website Studio project holds its own independent domain assignment. - A newly purchased domain starts with no existing content, so publishing to it carries no risk to any prior site. - Your original website's domain is only affected if you manually change its DNS settings or reassign it inside Website Studio. 🔍 How to Verify Your Publishing Destination Before Going Live Follow these steps to confirm the correct domain is assigned to your project before you click Publish: 1. Open your project in Website Studio. From the main dashboard, select the site you want to publish. 2. Go to Settings → Domain. In the left-hand navigation panel, click Settings, then select Domain. 3. Review the connected domain. The domain shown here is the exact destination where your site will be published. Confirm it matches your newly purchased domain and not your original website's domain. 4. Check DNS status. A green indicator or "Connected" status confirms the domain is properly linked. If the status shows "Pending" or "Not Connected," your site cannot go live on that domain yet, giving you extra time to verify before anything publishes. 5. Use the Preview function. Before publishing, click the Preview button in the top toolbar. This generates a temporary preview link that lets you review your full site as it will appear — without making it publicly accessible on your domain. Share this link for review or approval if needed. 6. Confirm and publish. Once you have verified the domain in Settings and reviewed the Preview, click Publish. Your site will go live only on the confirmed destination domain. 🛡️ Built-In Safety Mechanisms Website Studio includes several safeguards that prevent accidental publishing to the wrong destination: - Domain assignment is explicit. You must manually add and verify a domain inside each project. No domain is assigned automatically. - DNS propagation acts as a buffer. After connecting a new domain, DNS changes can take up to 48 hours to propagate. During this window, the domain is not yet live, giving you time to double-check everything. - Projects are isolated. Each Website Studio project operates independently. Changes in one project — including publishing — have no impact on any other project or any externally hosted website. - No overwrite without reassignment. Publishing a new project to Domain A will never affect a site currently hosted on Domain B. The two are entirely separate unless you explicitly reassign Domain B to the new project. ⚠️ What to Avoid To keep your original website fully protected, avoid the following: - Do not update the DNS records of your original website's domain to point to your new Website Studio project unless you intend to replace it. - Do not reassign your original domain inside Website Studio's Domain Settings. - If you are unsure which domain is currently assigned to a project, always check Settings → Domain before publishing. ✅ Quick Pre-Publish Checklist Run through this checklist every time you are ready to publish a new site: - Settings → Domain shows the correct new domain, not your original website's domain. - Domain status is "Connected" or matches the intended destination. - Preview link has been reviewed and the content looks correct. - DNS records for the new domain point to Search Atlas, not to any other hosting provider. - Original website's domain has not been modified in any way. 💬 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.

🔒 Wildcard SSL and 404 Redirect Routing in Website Studio

🔍 Overview Website Studio supports two important domain and routing features: wildcard SSL certificates for securing all subdomains under your root domain, and custom 404 redirect rules that send visitors to your homepage — or any valid URL — instead of displaying a raw XML error page. This article explains how both features work and how to get them configured for your site. 🔐 What Is Wildcard SSL? A standard SSL certificate secures a single domain (e.g., www.yourdomain.com). A wildcard SSL certificate secures the root domain and all of its subdomains at once (e.g., *.yourdomain.com), covering addresses like blog.yourdomain.com, shop.yourdomain.com, and any others you create. This is especially useful if your Website Studio project uses multiple subdomains, or if you plan to expand your site structure over time without requesting a new certificate for each subdomain. ⚙️ How to Request Wildcard SSL for Your Domain Wildcard SSL is not enabled automatically — it requires a quick setup step on our end. To request it: 1. Make sure your domain is already connected to your Website Studio project. 2. 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. 3. Provide your root domain name (e.g., yourdomain.com) and confirm the project it is linked to. 4. Our team will provision the wildcard SSL certificate and confirm once it is active. Once enabled, all current and future subdomains under your root domain will be covered automatically. No further action is needed on your end after the certificate is issued. 🚦 What Are Custom 404 Redirects? When a visitor lands on a URL that does not exist on your site, the server returns a 404 Not Found error. By default, some configurations display this as a plain XML error response, which is unhelpful for visitors and can negatively affect user experience and crawl efficiency. A custom 404 redirect automatically forwards anyone who hits a non-existent URL to a destination you choose — most commonly your homepage. This keeps visitors on your site and prevents search engines from indexing dead-end error pages. 🛠️ How to Set Up a Custom 404 Redirect You can configure 404 redirect routing directly inside Website Studio. Follow these steps: 1. Log in to your Search Atlas account and open Website Studio. 2. Navigate to your project and go to Settings. 3. Locate the Redirects or Routing section within your project settings. 4. Add a new redirect rule and set the source to the wildcard pattern for unmatched URLs (e.g., /* or the 404 error condition). 5. Set the destination to your homepage URL or any valid page on your site. 6. Choose 301 (Permanent) if the redirect is a long-term rule, or 302 (Temporary) if you may update it later. 7. Save your changes and test by entering a made-up URL on your domain to confirm the redirect fires correctly. Tip: A 301 redirect passes link equity to the destination page and signals to search engines that the old URL is permanently gone. Use 302 only when the redirect is genuinely temporary. ❓ Frequently Asked Questions - Will wildcard SSL automatically cover new subdomains I create later? Yes. Once a wildcard certificate is in place, any new subdomain you add under the same root domain is covered immediately. - Can I redirect 404s to a page other than my homepage? Yes. During setup, set the destination to any valid URL on your site, such as a contact page, category page, or custom error page you have built inside Website Studio. - Will the 404 redirect affect pages that do exist? No. The redirect rule only fires for URLs that do not match any existing page on your site. All live pages load normally. - How long does it take for wildcard SSL to activate? Certificate provisioning typically completes within a few minutes to a few hours after our team processes your request, depending on DNS propagation. 💬 Need Further Help? If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Header Edits Reverting After Publishing in Website Studio

🔍 Overview If you've hidden the navigation menu or made other edits to your site's header in Website Studio, you may notice that those changes look correct in preview but revert to the original state after publishing. This is a known behaviour related to how the shared header component is published across your site, and there are clear steps you can follow to resolve it. ⚙️ Why This Happens Your site's header in Website Studio is a shared component — meaning it exists once and is applied globally across every page. Because of this, edits to the header must be saved and published in a specific way. If the correct workflow is not followed, the platform may publish the page content without carrying over the header changes, causing them to appear to revert. Common reasons this occurs include: - Publishing an individual page instead of the shared header component separately. - Saving edits locally in the editor without triggering a full site publish. - A build error occurring silently in the background, which causes the latest header version to not be applied. ✅ How to Publish Header Changes Correctly Follow these steps to make sure your header edits — such as hiding the navigation menu on specific pages — are saved and published successfully. 1. Open Website Studio and navigate to the page where you made your header edits. 2. In the editor, locate the header component. It will typically be labelled as a shared or global element. 3. Make your desired changes (for example, toggling the navigation menu visibility). 4. Save your changes using the Save button within the header component editor — do not just save the page. 5. After saving, click Publish from the top toolbar. Ensure you are publishing the entire site, not just the individual page. 6. Wait for the publish process to complete fully. A success confirmation message should appear. Do not close the tab or navigate away during this step. 7. Once published, open your live site in a new browser tab (not the preview) to verify the changes are live. 💡 Tips to Avoid This Issue - Always publish the full site after editing any shared component, including the header or footer. - Do not rely on preview alone to confirm shared component changes — preview may show edits that have not been fully committed to the build. - If the publish button appears greyed out or unresponsive after editing the header, try refreshing the editor and re-applying your changes before publishing again. - Clear your browser cache before checking the live site to make sure you are not viewing a cached version of the old header. 🚨 If the Publish Fails or Changes Still Revert In some cases, a build error may occur in the background without a visible error message being shown. If your header changes continue to revert after following the steps above, try the following: 1. Refresh Website Studio and re-open the header component editor. 2. Re-apply your changes from scratch rather than assuming the previous edits were saved. 3. Publish the site again and watch the publish progress bar to confirm it completes without interruption. 4. If you see any error banner or the publish does not complete, take a screenshot of the message for reference. 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 YouTube Videos Not Showing in Published Blog

🔍 Overview If you've embedded a YouTube video in a blog post inside Content Studio and it looks fine in the editor, but doesn't appear on your published blog in Website Studio, a simple republish is usually all it takes to sync the content and render the video correctly on your live site. 🧠 Why This Happens Website Studio caches your blog content at the time of publishing. If you embed or update a YouTube video in Content Studio after the blog was originally published, those changes are not automatically pushed to your live site. You need to republish the post to force Website Studio to pull in the latest version of your content, including the embedded video. ✅ How to Republish Your Blog Post 1. In the left sidebar, click Website Studio to open the website builder at /website-studio. 2. Locate your blog project and open it. 3. Navigate to the blog post that contains the YouTube video. 4. Make a minor edit to the post if needed — for example, add a space or update a word — to mark the content as changed. This is not always required, but it ensures the platform registers new content. 5. Click Submit to republish the blog post to your live site. 6. Wait 1–2 minutes, then open your published blog URL in a new browser tab. 7. Hard-refresh the page by pressing Ctrl + Shift + R (Windows) or Cmd + Shift + R (Mac) to clear the browser cache. 8. Confirm the YouTube video is now rendering correctly. 🎥 Make Sure the YouTube Embed Is Set Up Correctly Before republishing, double-check how the video is embedded in Content Studio. An incorrect embed can prevent the video from displaying even after a republish. - Use the embed code, not a plain URL: In YouTube, click Share → Embed and copy the full <iframe> snippet. - Paste as HTML: In Content Studio, switch your blog editor to HTML / Source mode before pasting the embed code so it is not treated as plain text. - Avoid privacy-restricted videos: If the YouTube video is set to private or unlisted with restricted embedding, it will not play on external sites. Make sure the video's embed permissions are enabled on YouTube. 🛠️ Still Not Showing After Republishing? If the video still does not appear after following the steps above, try the following checks: - Confirm the blog post status shows as published and not draft inside Website Studio. - Test the live blog URL in a different browser or an incognito window to rule out a local cache issue. - Check that the YouTube video itself is publicly accessible and embeddable by testing the embed on a standalone HTML page. - If your blog is hosted on a custom subdomain, allow a few extra minutes for DNS and CDN propagation to complete before the update appears. 💬 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.

🔍 Troubleshooting Blog Post Display Errors After Publishing

This article covers a common display issue where a newly published blog post looks broken, unstyled, or incorrectly formatted on your live website. Because the exact cause can vary depending on your site's setup, our support team will need to investigate your specific configuration to identify and resolve the issue. 🔍 Common Causes - Editor mismatch: Content may have been created in one editor while the site's theme or layout is controlled by a different page builder, which can result in styling not being applied correctly. - Styling not applied on publish: Certain page builders require you to save or publish from within their own interface for styles to take effect on the front end. - Caching: A cached version of the page may be served to visitors even after changes are saved, making the post appear broken when it has already been corrected. 🛠️ What to Try First 1. Reload the post URL in a new private or incognito window to rule out a local browser caching issue. 2. Check whether the post was saved and published using the same editor or page builder that controls your site's layout and theme styling. 3. If you have access to your site's admin dashboard, verify that all relevant plugins are active and up to date. ✅ When to Escalate If the steps above do not resolve the issue, our team can investigate further. To help us assist you as quickly as possible, please have the following ready when you reach out: - The exact URL of the blog post showing the display error - A screenshot or screen recording of what the post looks like on the live site - The name of the page builder or editor plugin you are using (if known) - The date and approximate time you first noticed the issue 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.

📧 Connect Domain Email for Website Studio Forms

📋 Overview Website Studio lets you collect leads and inquiries through contact forms built into your site. To receive those submissions in your inbox, you need to connect a domain email address inside your project settings. This article also covers a common issue where blog posts appear on your site but do not open correctly when clicked. 🔌 How to Connect Your Domain Email for Form Submissions To set up email notifications for your Website Studio contact forms, navigate to your project's settings area within Website Studio and look for the section related to form submissions or email notifications. From there, you can enter the domain email address where you want to receive submission alerts and save your changes. If you are unsure where to find these settings, or if the option does not appear as expected in your project, our support team can walk you through the exact steps for your account configuration. ✅ Verifying Your Email Connection Works After saving your email address in the project settings, confirm that notifications are being delivered correctly: - Visit the live version of your site and submit a test entry through your contact form. - Check the inbox of the domain email address you connected. - If the test email does not arrive within a few minutes, check your spam or junk folder. - If the email is still missing, return to your project settings and confirm that your email address is saved correctly, then reach out to support for further help. 📝 Why Blog Posts Are Not Opening on Your Site If your blog posts are visible in the list on your site but clicking them leads to a broken page or no content, this is a known issue that can occur within Website Studio. The fix typically requires a configuration adjustment inside your project settings related to how blog post links are set up. To get this resolved, please contact our support team with the following information ready: - The name of the Website Studio project affected. - The URL of the blog post page that is not opening correctly. - A brief description of what you see when you click the blog post link (e.g., blank page, 404 error, redirect). Having these details ready will allow our team to identify the cause quickly and apply the correct fix to your project. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Custom Code and SSL on Website Studio

🔍 Overview Two of the most common issues in Website Studio involve custom code scripts not appearing in the published HTML and SSL certificate errors on the www subdomain. This article explains what these issues are and what information to have ready when contacting support to resolve them. ⚙️ Custom Code Not Appearing in Live HTML After adding a custom code snippet and publishing your site, you may notice the script is missing when you inspect the live page source. This is typically related to how Website Studio compiles custom code during the publishing process — the script may not be included in the final HTML output as expected. Because this involves backend compilation behavior, our team will need to investigate directly. To help us resolve this quickly, please have the following ready when you reach out: - The name of the affected Website Studio site or project. - The exact custom code snippet you added. - The live URL where the script is not appearing. - The approximate time you last published the site. - A screenshot or copy of the live page source showing the script is absent. 🔐 SSL Certificate Errors on the www Subdomain When you connect a custom domain to your Website Studio site, SSL certificates must cover both the root domain and the www subdomain. Issues with how the www subdomain is routed to the platform can result in a certificate error when visitors land on the www version of your site. Resolving SSL routing for the www subdomain requires backend configuration by our team. Please have the following ready when you contact us: - Your custom domain name (both root and www versions). - The exact SSL or browser error message you are seeing. - The name of your Website Studio site or project. - Any recent changes you made to your DNS settings. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Website Studio Publish Button Not Updating

🔍 Overview After making visual edits in Website Studio, the publish button may not update as expected after edits are made and saved. This can prevent you from republishing your site. This article explains what is happening and what to do next. ⚙️ Why This Happens This is a known issue with the Website Studio publish button. After making visual edits, the publish button state does not always update correctly, which means the interface may continue to show Published even when edits have been made. As a result, the republish option may appear unavailable. ✅ What to Try If your publish button is not updating after visual edits, try the following steps: 1. Refresh the page: After completing your edits, refresh your browser and return to Website Studio to see if the publish button state has updated. 2. Re-enter the editor: Navigate away from Website Studio and then return to your project. Re-opening the project can prompt the system to re-evaluate the publish state. 3. Make a minor additional edit: Inside the visual editor, make a small secondary change and save. This may trigger the publish button to become active again. 4. Try a different browser: If the issue persists, open Website Studio in a different browser to rule out a local caching problem. 📋 What to Document Before Contacting Support If none of the above steps resolve the issue, gathering the following information will help our team investigate quickly: - The name of the project or site you are editing - The browser and operating system you are using - A short screen recording or screenshot showing the publish button stuck on Published after edits are made - The approximate time and date the issue 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.

Fix Article Publishing Failures and Manage Photos

🔍 Overview If your articles are failing to publish, this is often related to a slug conflict — a situation where the URL associated with your article is already in use on your connected site. This article explains what slug conflicts are, general steps customers have taken to address publishing failures, and how to get support for photo management issues. ⚠️ Why Articles Fail to Publish: Slug Conflicts Explained Every article has a slug — the unique portion of its URL that identifies that page (for example, /my-article-title). A slug conflict can occur when that URL path is already in use on your connected site, which may prevent the article from publishing successfully. Common reasons a slug conflict occurs: - You previously published an article with the same title and it is still live. - A page or post on your site already uses the same URL path. - A draft was published, deleted, and republished without changing the slug. 🛠️ How to Resolve a Slug Conflict If you are experiencing a publish failure that may be related to a slug conflict, the general approach is: 1. Open the article that is failing to publish. 2. Locate the slug or URL/permalink setting for the article. 3. Change the slug to something unique — for example, from /healthy-recipes to /healthy-recipes-2025. 4. Save the updated slug. 5. Attempt to publish the article again. Note: If you are unsure which URL is causing the conflict, review your connected site's existing pages and posts for any matching URL paths before making changes. 🚀 Publishing an Article If you are still unable to publish after addressing a potential slug conflict, or if you are uncertain where to find the slug or URL settings within the platform, please reach out to our support team for guidance specific to your account setup. When contacting support, please have the following ready: - The name or title of the article you are trying to publish. - The exact error message you received when the publish action failed. - The URL or slug you were attempting to use. - The name of your connected site or project. 🖼️ Managing Article Photos If you are experiencing issues with article photos — such as missing images or wanting to replace an auto-assigned image with one of your own brand assets — please contact our support team. When reaching out, include: - The article name or URL. - A description of the photo issue (e.g., image missing, wrong image displayed, unable to update the image). - Any error messages you encountered. If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🌐 Website Studio Domain Not Showing After Publishing

🔍 Why Your Domain Isn't Showing Yet After you publish your Website Studio site and connect a custom domain, there is a waiting period before the domain becomes visible in browsers. This is called DNS propagation — the process by which your domain settings spread across servers worldwide. It typically takes 24 to 48 hours to complete, though it often resolves sooner. During this window, your site is live on our end, but your domain may not yet resolve correctly in all browsers or locations. This is normal and expected behavior. ✅ How to Check Your DNS Propagation Status You can verify whether your domain has propagated successfully without waiting or guessing: 1. Use a free external DNS lookup tool (such as dnschecker.org or whatsmydns.net) to confirm whether your domain is resolving correctly from different global locations. 2. Enter your custom domain into the tool and review the results. If propagation is still in progress, allow more time before troubleshooting further. 3. If the external check confirms your domain is resolving correctly, proceed to the browser cache steps below. 🗑️ Clear Your Browser Cache Even after DNS propagation completes, your browser may still show an old or blank version of your site because it has cached the previous DNS response. Clearing your cache forces your browser to fetch the latest information. Google Chrome: 1. Press Ctrl + Shift + Delete (Windows) or Cmd + Shift + Delete (Mac). 2. Set the time range to All time. 3. Check Cached images and files and Cookies and other site data. 4. Click Clear data, then reload your domain. Mozilla Firefox: 1. Press Ctrl + Shift + Delete (Windows) or Cmd + Shift + Delete (Mac). 2. Select Everything from the time range dropdown. 3. Check Cache and Cookies, then click Clear Now. Safari: 1. Go to Safari > Settings > Privacy. 2. Click Manage Website Data, then Remove All. 3. Reload your domain. You can also test your domain in a private or incognito window to bypass cached data instantly, without clearing your entire browser history. 🛠️ Flush Your Local DNS Cache Your operating system stores its own DNS cache separately from your browser. If clearing your browser cache doesn't help, flush your system's DNS cache as well. Windows: 1. Open the Start menu, search for Command Prompt, and run it as Administrator. 2. Type ipconfig /flushdns and press Enter. 3. Reload your domain in the browser. Mac: 1. Open Terminal (found in Applications > Utilities). 2. Type sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder and press Enter. 3. Enter your Mac password if prompted, then reload your domain. If your domain is still not resolving after completing all of the steps above and 48 hours have passed, please escalate. When reaching out, have the following ready: your custom domain name, the exact error message or behavior you see in the browser, and the timestamp of when you first published your site. 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 Content Genius WordPress Publishing Sync Errors

🔍 Understanding the Sync Error When Content Genius displays 'We're unable to sync with your WordPress site', it means the platform cannot establish a connection with one or more of your WordPress domains at the time of publishing. This can affect a single site or multiple connected domains simultaneously. What to Have Ready When You Contact Support This type of sync error requires investigation by our technical team. To help us resolve your issue as quickly as possible, please have the following information ready before reaching out: - The exact error message you are seeing (a screenshot is helpful) - The WordPress site URL(s) affected - The date and time the error first occurred - Whether the issue affects one site or multiple connected domains - Any recent changes made to your WordPress site, hosting environment, or Search Atlas connection settings If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix 404 Errors on Published Website Studio Pages

🔍 Overview After publishing a page in Website Studio, you may occasionally see a 404 error on the live domain even though the page status shows as published and ready inside the platform. This can affect new pages, blog posts, and pages in languages other than your primary site language. This article explains what is happening and how to escalate effectively so our team can resolve the issue for you. ⚙️ Why This Happens A 404 error on a published page is typically a routing issue on the platform side. When a page is published in Website Studio, the live domain's routing layer must register the new URL. In some cases this registration does not complete as expected, leaving the page inaccessible even though it appears published inside the platform. This is a known bug that requires backend investigation to resolve. 🚀 What You Can Try While Waiting 1. Wait a few minutes and hard-refresh. Open the live URL in a new private/incognito browser window and press Ctrl + Shift + R (Windows) or Cmd + Shift + R (Mac) to bypass any cached response. 2. Check that you are using HTTPS. Ensure the URL you are testing starts with https:// rather than http://. Copy the exact URL shown inside Website Studio and paste it directly into your browser. 3. Try republishing the page. Inside Website Studio, open the affected page and publish it again. This can sometimes prompt the routing layer to re-register the URL. If the page is still returning a 404 after attempting the steps above, this will need to be investigated by our support team. 📋 What to Have Ready When You Escalate To help our team resolve this as quickly as possible, please have the following information ready before reaching out: - The exact live URL that is returning the 404 error - The name of the project or website in Website Studio - The page name and the language it was created in (if applicable) - The approximate date and time when you first noticed the error - Any screenshot or screen recording showing the 404 and the published status inside the platform If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.

🛠️ Fix Content Genius Publishing Failures with Elementor

🔍 Overview Content Genius in Search Atlas lets you publish articles directly to your WordPress site. When Elementor is your page builder, a few specific conditions must be met before publishing works correctly. This article walks you through the required setup, common failure points, and a step-by-step diagnostic flow so you can publish without errors. ✅ Prerequisites Before You Publish Before attempting to publish from Content Genius, confirm all of the following are in place: - Search Atlas WordPress plugin is installed and activated on your site. Content Genius communicates with your site through this plugin — without it, no publishing connection exists. - The plugin is authenticated with your Search Atlas account. Go to your WordPress dashboard, open the Search Atlas plugin settings, and verify your API key is saved and the connection status shows as active. - Your WordPress user role has publishing permissions. The connected account must have at minimum an Editor or Administrator role. - Elementor is active on the target page template you intend to use. If Elementor is installed but not set as the editor for that post type, the integration will not trigger correctly. - Your site URL in Search Atlas matches your live domain exactly, including the correct HTTP or HTTPS prefix and no trailing slash mismatches. 📋 Step-by-Step: Publishing an Article from Content Genius 1. Open Content Genius and finish writing or importing your article. 2. Click the Publish button in the top-right area of the Content Genius editor. 3. In the publish panel, select your connected WordPress site from the dropdown. If no site appears, your plugin connection is not active — see the section below. 4. Choose your target post status: Draft, Pending Review, or Publish. 5. Select the post category, featured image, and any custom fields required by your theme. 6. Click Send to WordPress. A success confirmation will appear when the article transfers correctly. 7. Go to your WordPress dashboard and open the post. If Elementor is your editor, click Edit with Elementor to apply your template or layout after the content has been received. Important: Content Genius sends article content as a standard WordPress post. Elementor styling and layout are applied inside WordPress after the content arrives — they are not set inside Content Genius itself. Expecting the full Elementor layout to render inside Content Genius is a common misunderstanding. ⚠️ Common Errors and How to Fix Them - "No sites connected" in the publish dropdown — The Search Atlas WordPress plugin is not installed, not activated, or the API key has not been saved. Reinstall the plugin and re-enter your API key from your Search Atlas account settings. - Publish button appears to complete but the post never appears in WordPress — Your domain URL in Search Atlas does not match the actual WordPress site address. Check both your WordPress general settings and your Search Atlas site settings for an exact URL match. - Content arrives in WordPress but Elementor shows a blank or broken layout — This is an Elementor-side issue, not a Content Genius issue. The content was delivered successfully. Open the post in Elementor and apply or reassign your page template. Elementor's Flexbox or Grid Container settings are irrelevant to the Content Genius publishing step. - Authentication error when publishing — Your API key may have been regenerated. Go to your Search Atlas account, copy the current API key, and re-paste it into the Search Atlas plugin settings in WordPress, then save. - Post publishes as wrong post type — Confirm the post type setting in the Content Genius publish panel. Some Elementor themes use custom post types; select the correct one from the dropdown before sending. 🔎 Quick Diagnostic Flow 1. Can you see your site in the Content Genius publish dropdown? No → Fix your plugin installation and API key first. 2. Does the publish action return a success message? No → Check your domain URL match and WordPress user permissions. 3. Does the post appear in WordPress? No → Check your WordPress REST API is not blocked by a security plugin or firewall. 4. Post is in WordPress but layout looks broken? → This is an Elementor template issue inside WordPress, not a Content Genius error. Reassign your Elementor template to the post. 🔗 Backlink Purchase Frequency Best Practices If you are also managing link-building alongside your content publishing, Search Atlas provides dedicated tools under Left sidebar → Authority (Press Releases) for Cloud Stacks and press releases. Here are the recommended frequency guidelines: - Cloud Stacks: Cloud Stacks are best built once per domain or campaign target as a foundational authority layer. You do not need to repeat them frequently. Navigate to Left sidebar → Authority (Press Releases) → Cloud Stacks to set up or review existing stacks. - Press Releases: A cadence of one to two press releases per month is generally safe and effective for most sites. Avoid large sudden spikes in press release volume. Access this at Left sidebar → Authority (Press Releases) (the main Authority page at /outreach/press-release). - Link Lab (Backlinks): For purchased or outreach backlinks, a gradual ramp is always recommended — start with a small number of links per month and increase over three to six months. Sudden large link acquisition can trigger search engine scrutiny. Review your existing backlink profile before purchasing new links by going to More Features → Backlinks → Backlink Research and identify gaps with More Features → Backlinks → Link Gap Analysis. - General rule: Diversify link types across press releases, cloud stacks, and editorial links. Do not concentrate all link-building into one channel in the same period. 💬 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.

🛠️ Website Builder: Published Pages Show Only Header and Footer with No Body Content

If a page in your Website Builder project loads its URL but shows only the header and footer with no body content, your project needs to be republished. This happens when pages are created, edited, or regenerated after the last publish — including pages the platform modifies automatically during AI generation runs. A republish restores the missing content. ⚠️ Why Published Pages Can Show a Blank Body When you publish your Website Builder project, Search Atlas generates a live snapshot of every page at that moment. Pages added, edited, or regenerated after that last publish are not included in the deployed snapshot — including pages the platform creates or modifies automatically during an AI generation run — and no automatic republish is triggered. The site URL resolves and the shared layout (header and footer) loads correctly, but no body content exists in the snapshot for those pages yet. Search Atlas engineering has confirmed that automatic republishing after platform-driven page changes is a known gap, and a fix is currently in progress. Until it ships, manually republishing your project is the supported workaround. 🔍 How to Confirm This Is Your Issue Check for all four symptoms on the affected pages: - The page URL loads without a 404 error. - The site header and footer render correctly. - The area between the header and footer is completely blank. - The affected pages were created, edited, or regenerated (including by the AI agent) after the most recent project publish. If all four apply, republishing the project will resolve the issue. 🔄 How to Fix It: Republish Your Website Builder Project Republishing forces Search Atlas to regenerate and deploy all pages — including any added, edited, or regenerated since the last publish. 1. Open Website Studio from the left sidebar of your Search Atlas dashboard. 2. Select the project with the affected published pages. 3. Click Publish or Republish in the top-right corner of the editor. - Publish appears if the project has never been deployed. - Republish appears if it has been deployed before. - Both actions regenerate and deploy all pages. 4. Wait for the green success notification in the top-right of the editor and for the button to return to its idle state — this confirms deployment is complete. 5. Reload the affected URLs in a new private or incognito tab to bypass browser cache, and confirm the body content now appears between the header and footer. After republishing, all pages — including those created, modified, or regenerated since the previous publish — will render their full body content. 💡 When to Republish After Editing Your Project Republish your project any time you or the platform make changes, including when you: - Add one or more new pages to the project. - Make significant content or layout changes to an existing page. - Update the site-wide header, footer, or layout template. - Rename or change a page's URL slug. - Run an AI generation that creates or rewrites pages in the project. Republishing after each batch of changes ensures the live snapshot always reflects the current state of your project. 🛟 Still Not Working? Contact Search Atlas Support If body content is still missing after a successful republish, or if the republish does not produce a visible website, contact Search Atlas Support. A separate known publish-time issue currently in progress with engineering can, in some cases, affect the result of a republish — the support team can confirm whether your project is impacted and apply the appropriate fix. When you contact support, include: - Your Search Atlas account email. - The Website Builder project name. - The full URLs of the affected pages. - The approximate time of your most recent republish attempt. - A screenshot of the blank page (or the unexpected publish output) if available. The support team will escalate to engineering and track the issue against the active known-issue tickets so you receive an update when the platform-level fix is released. 🎯 Republishing your Website Builder project is the fastest way to restore missing body content on published pages, including pages updated automatically by AI generation runs. If pages still appear blank after republishing, contact Search Atlas Support with your project name and the affected page URLs so the team can investigate further.

🚫 Cancel Wrongly Bulk-Published PRs and Recover HDC Credits

🔍 Overview If Atlas Agent triggered a bulk publication for the wrong press releases, act quickly. The publications can be stopped before they go live, and the HyperDrive Credits (HDC) spent on those placements can be refunded to your account. This article explains what happens, what you can do immediately, and how to get the issue fully resolved. ⚠️ Why This Happens Atlas Agent can initiate bulk PR publications rapidly. If the wrong press releases are selected before the action is confirmed, the publications may begin processing immediately. Once triggered, you cannot cancel them yourself from within the platform — intervention from the Search Atlas team is required to stop the placements and protect your credits. 🚀 Step 1 — Contact Support Immediately Speed matters. The sooner the team is notified, the more likely the publications can be halted before they go live. 1. Reach out to the Search Atlas support team as soon as possible. 2. In your message, include the following information: - Which press releases were published by mistake (titles, URLs, or any identifying details you have) - Approximately when the bulk publication was triggered - The number of HDC you believe were consumed Providing these details upfront allows the team to escalate to the PR team without delay. ⚙️ Step 2 — What the Team Does to Stop the Publications Once your request is escalated, the PR team will work on the back end to stop the affected press releases from being distributed to publishers. You do not need to take any action inside the platform for this step — the team handles it entirely on the back end. Once the team has acted, the affected PRs will no longer show as actively publishing. You can log in to the platform to check the status of your press releases. 💡 Step 3 — HDC Refund Processing After the publications are halted, the team will process a refund of the HDC consumed by the mistaken bulk publication. The refund is applied directly to your account balance — you do not need to submit a separate request for it. 📊 Step 4 — Verify Your Credit Balance Once the team confirms the refund has been processed, check your HDC balance inside the platform to confirm the credits have been restored. If the balance does not look correct after the team has confirmed the refund, reply to your support conversation and the team will investigate further.

Fix www Subdomain SSL and Routing Errors in Website Studio

What This Article Covers If your website's www subdomain (e.g., www.yourdomain.com) is not working correctly or showing errors, the cause is often related to how the www subdomain is configured in your DNS settings. This article walks you through how to set up your www subdomain properly in Website Studio. Why This Happens When you set up a custom domain in Website Studio, the root domain (e.g., yourdomain.com) and the www subdomain (e.g., www.yourdomain.com) need to be configured separately in your DNS. If the www subdomain is not set up correctly, SSL and routing issues can occur. How to Fix It — Update Your DNS Records You will need access to your domain registrar or DNS provider (for example, GoDaddy, Cloudflare, Namecheap, or similar). Follow these steps: 1. Log in to your DNS provider and navigate to the DNS management section for your domain. 2. Check your existing DNS records for www. Look for a record with the Name (or Host) set to www. 3. Add or update a CNAME record with the following values: - Type: CNAME - Name / Host: www - Value / Target / Points to / Alias (these are all the same field, just labelled differently by each DNS provider): the preview URL provided by Website Studio when you connected your custom domain 4. Save the record. DNS changes can take anywhere from a few minutes to 48 hours to propagate globally, though many users see the fix take effect almost immediately. Where to Find Your Website Studio Preview URL Your unique preview URL was provided when you connected your custom domain in Website Studio. If you no longer have it, please contact our support team and we will retrieve it for you. What to Check If the Issue Persists After DNS Update After updating your DNS records, keep the following in mind: - Allow time for propagation. Most changes resolve within minutes, but full global propagation can take up to 48 hours. - Clear your browser cache and try loading the www URL in a private/incognito window to rule out cached content.

🛠️ Website Studio AI Creating Wrong Pages or 404 Errors

🔍 What Is This Issue? Some customers have reported that the Website Studio AI assistant creates unexpected pages — such as blog posts or website analysis pages — instead of carrying out the requested action (for example, updating a CTA link). This can result in 404 errors and unnecessary credit usage each time you attempt to correct the behaviour. This is a known issue where the Website Studio AI assistant hallucinates, generating unintended pages rather than performing the action you specified. If you are experiencing this behaviour, the steps below will help you address it. ✅ What You Should Do Right Now If you are seeing unexpected pages being created or 404 errors in Website Studio, follow these steps: 1. Clear your browser cache and cookies. Outdated cached data can sometimes cause the platform to behave unexpectedly. 2. Try again in a private or incognito window. This rules out any browser extension or cached session interfering with the AI assistant. 3. Return to Website Studio and retry your original instruction. Be as specific as possible in your request to help the assistant interpret it correctly. 4. Delete any unwanted pages that were incorrectly created. Navigate to your project in Website Studio and remove the pages that were generated in error. 💳 Credits Used Due to This Issue If the AI assistant consumed credits while malfunctioning — for example, by repeatedly creating wrong pages as you tried to fix the issue — you may be eligible for a credit refund as a courtesy. To request a credit review, please reach out to our support team. Describe the dates and actions affected so the team can review your account accurately. ⚙️ If the Problem Continues If you continue to see the AI assistant creating wrong pages or ignoring your instructions, please gather the following information before contacting support: - Note the exact instruction you gave the assistant and what it did instead. - Record approximately when the behaviour occurred (date and time). - Note whether any new pages were created and what type they were labelled as (blog, landing page, etc.). Having this information ready will help the support team investigate quickly and escalate to engineering if needed. If you need further assistance, please don't hesitate to reach out to our support team so we can look into your specific case.

🛠️ Fix Website Studio Custom Domain Errors (404, SSL, DNS Proxy)

Use this article to diagnose and fix the most common Website Studio custom domain errors — 404 pages, SSL warnings, and DNS failures — and to know when an issue clears on its own versus when to contact support. The most overlooked fix is disabling a DNS proxy that blocks CNAME validation. ⏳ When to Wait vs. When to Contact Support After you connect a custom domain to your Website Studio site, you may see errors such as 404 Page Not Found, Your connection is not private, This site can't be reached, or DNS not resolving. In most cases the setup did not fail — DNS changes or SSL certificates are still processing. Wait in these situations: - Wait up to 48 hours while DNS is propagating or an SSL certificate is being issued — these delays are usually temporary. - If you see no progress at all (no status change, no error message) after 24 hours, contact support instead of continuing to wait. Contact support immediately if any of these apply: - Your domain is stuck on Pending verification with no error message and no progress for more than 48 hours. This is a known issue where the verification system may fail silently without displaying an error in the UI. Contact support with your domain name — the backend must be checked manually. - You see a Domain already registered error. - Your domain does not appear in your account after purchase. - A previously working site suddenly shows a Your connection is not private warning. This indicates an expired SSL certificate. The auto-renewal system has a known issue where certificates are not always reissued automatically before they expire, so the secure connection breaks. As a workaround, contact support with your domain name so the certificate can be renewed manually — do not wait for it to self-resolve. 🌐 How a Website Studio Domain Connection Works Understanding the connection chain helps you spot which step is failing. When someone visits your domain, this happens in order: 1. The visitor enters your domain. 2. Your DNS provider resolves the domain. 3. The CNAME record points to Website Studio hosting. 4. The DNS Validation & Publishing Status moves through Pending → Validating → Connected. 5. Website Studio serves your site. 6. The SSL certificate secures the connection. If any step is incomplete or misconfigured, your site shows an error. The status indicator tells you where the chain stopped. 🧩 Cause 1 — DNS Has Not Fully Propagated The most common reason for domain errors is DNS propagation delay. After you add your CNAME record, the update must spread across global DNS servers. Expect: - At least 2 hours in most cases. - Up to 24–48 hours on slower networks. During this window, different visitors may see different results — the old site, a DNS error, or a 404 — while others already see the new site. This is expected and usually clears on its own. One important exception: if you have already waited a full day or more and still see errors, the problem is more likely a DNS proxy conflict (see Cause 2) than propagation. A proxy will not clear with time, so move to the next section instead of waiting longer. 📊 What Each DNS Validation & Publishing Status Means Inside Website Studio, your domain displays one of these statuses. The legacy red DNS Failed label is no longer shown during normal propagation. - Pending — DNS records have been submitted and are waiting to propagate. Expected during the first 2+ hours. - Propagating / Validating — the system is actively checking your DNS records. - Connected — your domain is verified and live. 🔌 Cause 2 — Your DNS Proxy Is Enabled If your CNAME record is correct but the domain still fails to connect after a day or more, a DNS proxy is the likely cause. Some DNS providers (for example, Cloudflare) route your record through their own proxy by default — often shown as a proxied toggle or an orange cloud icon. A proxied record hides your real CNAME target, so Website Studio cannot validate it and the connection stays stuck. To fix it: 1. Open your DNS provider's DNS management panel (for example, Cloudflare, Route 53, or GoDaddy) and find the CNAME record for your Website Studio domain. 2. Look for a DNS proxy, orange cloud, or CDN toggle on that record. This setting routes traffic through the provider's network and hides your real CNAME target. 3. Switch the proxied setting off so the record is set to DNS only (unproxied), then wait about 5 minutes for the change to propagate. If you cannot locate this setting, contact your DNS provider's support. 4. Save the record. 5. Return to Website Studio and reverify DNS for the domain. 6. If errors remain from earlier attempts, clear your browser cache (or open the site in a private window) and reload. Once the proxy is off and DNS is reverified, the status moves to Connected and your site loads normally. 🔤 www Subdomains: Use a CNAME, Not an A Record For www subdomains, add a CNAME record (not an A record) to your DNS provider, and delete any existing A record for www. If you see SSL errors only on www, confirm your DNS provider has not reverted the record to A record format. 🎯 You now know how to tell a temporary delay from a real misconfiguration: wait for propagation and SSL within 48 hours, disable a DNS proxy if your CNAME won't validate, and contact support with your domain name for silent pending states or expired SSL certificates.

🔒 Fix SSL Certificate Failures Caused by Conflicting A Records in Website Studio

If SSL certificate generation fails in Website Studio despite correct DNS setup and multiple retries, your domain likely has conflicting A records. Remove any A records not pointing to Search Atlas's IP address (34.148.211.207) and retry provisioning to resolve the issue. ⚠️ Why Multiple A Records Block SSL Provisioning When Website Studio provisions an SSL certificate for your custom domain, the certificate authority verifies that your domain resolves to the correct server. If your DNS has multiple A records and any of them point to a different IP address, the verification fails — even if one correct record also exists. Your domain must have exactly one A record pointing to Search Atlas's IP address: 34.148.211.207. Any additional A records pointing elsewhere will block SSL issuance. 🔍 How to Check Your Domain's A Records Use a free DNS lookup tool to inspect your current A records before making any changes. 1. Go to a DNS lookup tool such as dnschecker.org or MXToolbox. 2. Enter your domain name and select A Record as the lookup type. 3. Review the results. If you see more than one IP address listed under A records, you have conflicting entries. 4. Flag any A record whose value differs from 34.148.211.207 — you'll delete those in the next section. If all A records already show only 34.148.211.207, contact Search Atlas Support — the issue may be elsewhere in your DNS configuration. 🛠️ How to Remove Conflicting A Records Log in to your DNS provider — for example, GoDaddy, Cloudflare, Namecheap, or your domain registrar's control panel. 1. Navigate to the DNS Management or DNS Zone Editor section for your domain. 2. Locate all A records for the root domain (@) or the specific subdomain you are connecting to Website Studio. 3. Delete all A records except the one with the value 34.148.211.207. 4. Confirm that exactly one A record remains, pointing to 34.148.211.207. 5. Save your changes. DNS changes typically apply within minutes but can take up to 48 hours to propagate globally. Confirm full propagation using the DNS lookup tool from the previous section before retrying SSL provisioning. 🔄 How to Retry SSL Provisioning in Website Studio Once DNS has propagated and only the correct A record is active, return to Website Studio to retry certificate generation. 1. Log in to Search Atlas and open Website Studio. 2. Select the project where SSL provisioning previously failed. 3. Go to Settings → Domain. 4. Click Retry SSL or Provision Certificate. You'll see a confirmation message once the certificate is successfully issued. If provisioning fails again, verify that DNS has fully propagated and that no conflicting A records have been re-added. 🎯 You now know how to identify and remove the conflicting A records that block SSL provisioning in Website Studio. If certificate generation continues to fail after fixing your DNS, contact Search Atlas Support for further assistance.

🛠️ Pub Media Articles Publishing as Drafts in WordPress MetaSync

A confirmed bug in the WordPress MetaSync plugin (WP-277) silently saved Pub Media articles as Drafts instead of publishing them live. Update the patched plugin release, then use the steps below to identify and republish any affected posts. 🐛 Why Pub Media Articles Published as Drafts A confirmed bug in the WordPress MetaSync plugin caused articles sent from Pub Media to default to Draft status in WordPress — even when the publish payload was correctly configured on the Pub Media side. No error message appeared in either Pub Media or MetaSync, making this a silent failure detectable only by checking WordPress post status directly. ⚠️ Scope: This issue affects only the Pub Media → MetaSync publishing flow. Content Genius users publishing to WordPress via MetaSync are not impacted. - 📋 Affected workflow: Pub Media publishing via the WordPress MetaSync plugin - 🔴 Symptom: Articles appear as Drafts in WordPress instead of Published - 🔇 Failure type: Silent — no error or warning surfaces in Pub Media or MetaSync - 🔍 SEO metadata: Expected to be preserved — verify title, description, and schema fields on each affected post before republishing 🔍 How to Confirm You Are Affected Check whether your Pub Media articles were silently saved as drafts: 1. Log in to your WordPress dashboard. 2. Navigate to Posts → All Posts. 3. Click the Drafts filter at the top of the list. 4. Look for articles you intended to publish from Pub Media. If they appear here instead of under Published, you are affected. ✅ You are affected when Pub Media articles appear as Drafts in WordPress with no corresponding error in Pub Media or MetaSync. 🔧 How to Fix Articles Stuck as Drafts ✅ This bug has been fixed (tracked as WP-277) — follow the steps below to update your plugin and restore affected posts. ⬆️ Step 1 — Update the MetaSync Plugin 1. In your WordPress dashboard, go to Plugins → Installed Plugins. 2. Find WordPress MetaSync and check the version number shown below the plugin name. 3. Click Update if an update is available to install the patched release containing the WP-277 fix. If you are unsure which version contains the fix, check the MetaSync WP-277 release notes or contact Search Atlas support to confirm. ⚠️ Do not skip this step. Manually publishing existing drafts without updating the plugin means new articles sent from Pub Media may still land as drafts. 📝 Step 2 — Publish Affected Draft Posts After updating the plugin, go to Posts → All Posts and click the Drafts filter. Choose one of the following methods: - ✏️ Individual publish: Open each affected post and click Publish. - ⚡ Bulk publish: Select all affected posts using the checkbox at the top of the list, choose Edit from the Bulk Actions dropdown, set the status to Published, and click Update. 🔄 Step 3 — Re-send from Pub Media (Optional) If you prefer posts to go live through the original Pub Media publish flow, trigger a new publish from Pub Media after updating the plugin — the updated plugin will now correctly honor the publish status in the payload. ⚠️ Important: Re-sending will overwrite any manual edits made to the draft in WordPress. If you have edited the draft directly, publish it from WordPress first rather than re-sending. 🆘 When to Contact Support Contact the Search Atlas support team if any of the following apply: - ❌ Articles still publish as drafts after updating the MetaSync plugin - 🔒 You cannot update the plugin independently (for example, in a managed or agency-managed WordPress environment) - ⚠️ You notice other silent status mismatches in the Pub Media → MetaSync workflow - 📦 You have a large volume of affected drafts and need assistance with bulk remediation When reaching out, include your MetaSync plugin version number and a screenshot of the Drafts list in WordPress to help the team diagnose quickly. ❓ Frequently Asked Questions 🤔 Why did no error appear when my articles published as drafts? The bug caused MetaSync to silently override the publish status in the payload received from Pub Media. Because nothing failed visibly, the issue was only detectable by checking WordPress post status directly. 🏷️ Is my SEO metadata still intact on the draft posts? SEO metadata — including title tags, meta descriptions, and any custom fields set in Pub Media — is expected to be preserved on the draft. Verify title, description, and schema fields on each affected post before republishing to confirm everything is in place. 👥 Are all Pub Media users affected? Only customers publishing via the WordPress MetaSync plugin are affected. Other Pub Media publishing integrations are not impacted. Content Genius users publishing to WordPress via MetaSync are also not affected. 🔁 What if I already resent articles from Pub Media before updating the plugin? Re-sent articles may also be saved as drafts if the plugin was not yet updated. After updating, check your Drafts list for both the original and any re-sent versions. Remove duplicates before publishing to avoid duplicate content issues on your site. 🏗️ What if my WordPress host manages plugin updates and I cannot update myself? Contact your hosting provider or WordPress administrator and request an update to the latest version of the MetaSync plugin (the release containing the WP-277 fix). If you need help communicating the issue to your host, reach out to the Search Atlas support team and we can provide the technical details needed. 🔮 Will this happen again after I update the plugin? No. The bug is resolved in the patched release of MetaSync (WP-277). Once updated, new articles sent from Pub Media will publish live as expected — no further action is needed for future posts. 🎯 Update the WordPress MetaSync plugin to the patched release (WP-277), then publish any affected drafts from your WordPress dashboard — individually or via Bulk Actions. If articles still land as drafts after updating, contact our support team with your plugin version number and a screenshot of the Drafts list.