top of page


If you are one of thousands who is setting out on a digital adventure, you’ve most likely struggled with which domain, or domains, to register to protect your idea from anyone who might try to capitalise on your hard work. This can be a difficult task, as many entrepreneurs struggle to choose one domain, never mind several.


Brand protection

Many major corporations take brand protection very seriously. For example, in 2015, Google’s parent company Alphabet actually registered the domain abcdefghijklmnopqrstuvwxyz.com. The domain is far too long to be used, and instead, Alphabet operates under abc.xyz. However, the example demonstrates the lengths – literally! – that business owners will take to protect their creations.


While the US doesn’t officially own the .com top level domain, most US companies begin with a .com domain, just as UK companies begin with a .co.uk domain. The .com domain extension has now become an international web address and appears in search engine results around the globe, which is why many businesses choose the .com version first. However, there are some benefits to registering both a .com and a .co.uk that you may not know about. Of course, owning both is not an absolute necessity, but ask yourself one simple question:


How will I feel if someone registers the .com version of my domain as a direct competition to my business?

If the thought of another business operating under your brand name makes you uncomfortable, it should. As long as the domain is floating around unclaimed, anyone can register it and use it for their own purposes.


The perks of monopolising your brand

Keep in mind that if you were to buy every domain available that included your brand name, you would burn through your budget very quickly. There are hundreds of gTLDs (Generic top-level domains) from .guru to .club that could include your brand. So, before you begin bulk registration of hundreds of new domains, take a moment to prioritise.

There are a few reasons to register a domain outside of your main web address. The first is to prevent anyone else from using it. The second is to use a new domain to reach new audiences. The third, and perhaps most appealing, is to take advantage of the SEO benefits that come with domain redirects. While you may not be concerned with international sales, you are most likely interested in protecting your ideas, and who wouldn’t like a little push in search engine results. When operating with both .com and a .co.uk domains, your website will appear in UK searches as well as international searches due to the .com. Registering both a .com and a .co.uk for your website is a beneficial move for any online enterprise.


The best of both worlds

Once registered, all that’s left is to set the redirect and watch your traffic grow. Rest easy knowing that your domain is protected from squatters. So why not protect your brand and get an SEO benefit in return by owning both the .com & .co.uk versions of your online business domain name?





Ref: -

2 views0 comments

Knowing whether your pages have been crawled (discovered by Google) or indexed (stored in Google’s index), or whether your structured data markup is valid, for example, can help you fine-tune your online presence and make large leaps in search visibility.




For years, Google has provided this information via Search Console, its platform for measuring search traffic and performance. To make those insights and tools more accessible to all business owners and SEO professionals, Wix now offers an approachable way to monitor and understand your site’s issues and indexing status at scale.




The Wix Site Inspection tool enables you to keep an eye on your site’s technical health, mobile usability, rich result eligibility, and more, without having to pull the data manually or leave the Wix dashboard.




In this article, we’ll discuss:




The Wix Site Inspection tool




Our Site Inspection tool enables you to monitor the status of your pages in Google’s index from within your Wix dashboard. The data within the Site Inspection dashboard (shown below) comes directly from Google via its URL Inspection API.



The Wix Site Inspection dashboard.


The Site Inspection tool is organized to show you:


  • The proportion of your pages that Google has indexed and excluded

  • The most common status details associated with your pages

  • An overview of your site’s usability on mobile devices

  • The index status, status details, mobile usability, and rich results eligibility for each of your URLs



This can be very valuable information because URLs that aren’t indexed aren’t eligible to show in Google’s search results, meaning that your potential clients, customers, and visitors will never discover those pages in Google Search.




How to get started with the Wix Site Inspection tool


To access your Site Inspection dashboard, first, go to your Wix dashboard. In the left-hand navigation panel, click on Marketing & SEO, and then SEO Tools from the dropdown menu. Finally, select Site Inspection.



If this is your first time accessing the Site Inspection tool, then you’ll be prompted to inspect your site (as shown above). Because the data comes from Google, your website must first be published and connected to Google Search Console (GSC). Once you’ve run the inspection, you’ll be taken to the Site Inspection dashboard.




The Site Inspection dashboard at a glance


The top of the Site Inspection dashboard includes a Highlights section that can help you understand your site’s overall health in terms of Google indexing and mobile usability (how well your site pages work on mobile devices).



Let’s take a closer look at each of the three sections that make up your Site Inspection Highlights.




Index status overview


This section tells you how many of your pages Google has indexed or excluded from its index. Pay attention to the number of pages that fall into the various status categories, as they can indicate whether pages have issues or don’t appear in search results, for example.




Indexation statuses include:


  • Valid — The page is indexed and can appear in search results. (This does not guarantee that it will appear in search results.)

  • Warning — Google may or may not have indexed this page depending on its specific warning status. This means that the page may not appear in search results.

  • Invalid — Google did not index this page due to an error on it.

  • Excluded — Google crawled this page, but decided not to index it.

  • Unspecified — Google doesn't currently have any information for this page.



As you plan your optimizations based on this information, it’s worth remembering that not all your pages should be available via search engines. “Thank you” pages and gated content, for example, may not provide value to users coming from the search results.




Top status details


The top status details provide additional context for the information in the index status overview (discussed above). Essentially, these are the reasons why pages couldn’t be indexed or haven’t yet been indexed.




Below are explanations of some of the status details you may see:


  • Submitted and indexed — You submitted the URL and Google has indexed it. It can appear in search results.

  • URL is unknown to Google — The URL has not yet been found by Google. This may be because it’s a new page or it has no links directing to it.

  • Crawled - currently not indexed — Google has crawled the page, but decided not to index it for search results at the moment (it may or may not be indexed in the future).

  • Discovered - currently not indexed — Google found the page, but decided not to crawl it for search results at the moment. This is usually because Google decided that crawling this page would overload your site and rescheduled crawling for a later time.

  • Indexed, not submitted in sitemap — Google indexed this page, even though it's not included in your site’s sitemap. It can appear in search results.



Mobile usability


This section provides an overview of how well your site pages work on mobile devices. While this does not specifically pertain to indexation, it does relate to mobile-friendliness, which is a Google ranking factor. Additionally, mobile-friendly sites make it easier for users to access content and convert.




Here is an explanation of the details listed in this section:


  • Valid — The page meets a minimum level for mobile usability and should work well on mobile devices. A page may still have some mobile usability issues even if it displays this status.

  • Issues — This indicates that a page has issues that will prevent it from working well on mobile devices.

  • Invalid — Google did not index this page due to an error on it. You may be able to request that Google index the page after you fix the error.

  • Unspecified — Pages for which Google currently has no information. This may be because Google couldn’t retrieve the page or test its mobile usability at the time of the report.



Within your Full Report section (more on that below), “No data” may also show as the mobile usability status of an individual page. This means that Google has not indexed the page and that it doesn’t have any information about the page’s mobile usability.




Full Report section


While the Highlights section presents information that’s useful for understanding the overall health of your site, the Full Report section provides page-level details, which can help you make specific fixes and optimisations.



In this section, you’ll see:


  • Page name

  • Type of page (e.g., Main Page, Blog Post, etc.)

  • Index status (e.g., Valid, Excluded)

  • Status details (e.g., Submitted and indexed, Unknown to Google, etc.)

  • Mobile usability status (e.g., Valid, Invalid, No data)

  • Rich results eligibility



You can learn more about an individual page’s status and details by selecting it in the Full Report. Doing so launches the page result information panel (shown below) for the associated page.



Here, you can review more details about a page’s coverage status, mobile usability, and rich results eligibility. The Learn more links direct you to the Site Inspection tool’s Wix Help Center page, where you can dig into specific statuses to correct errors that may be hindering your search visibility or mobile user experience.




Additionally, you can view the URL inspection report within GSC for the associated page by clicking on the Google Search Console link at the bottom of the panel. There, users with owner or full user access can request that Google crawl that particular URL.




Ways to use Site Inspection data


Site Inspection data can act as a portal into how Google sees your site, which is invaluable for troubleshooting and planning your optimizations. Below are a few scenarios where the Site Inspection tool may be particularly helpful.




Identify and troubleshoot content that hasn’t been indexed


The Full Report displays a list of your site’s URLs. You can scan the index status column to quickly identify pages that haven’t been indexed (these pages won’t be eligible to show in Google search results).




For pages that should be indexed, you can reference the status details (coverage) column to learn more about the page’s status. For example, a “Crawled - currently not indexed” status could indicate that Google thinks the content is thin or identical to content on another URL, while the “Unknown to Google” status likely means that Google has yet to discover the content.




Improve your mobile usability


In instances where a page shows an “Invalid” mobile usability status, the mobile usability section of that page’s result information panel may explicitly tell you why. This can enable you to quickly identify the issue and implement a fix.



Our Site Inspection Help Center page includes a detailed section about the various mobile usability statuses. For an even more comprehensive review of a page’s mobile-friendliness, paste the URL into Google's Mobile Friendly test tool.




Verify rich result eligibility


Rich results, which are generated via structured data markup, are search listings that contain information beyond the standard URL, page title, and description. Since they’re visually distinct from traditional results, they may make your listings stand out.



An example of an FAQ rich result.


The rich results column of the Full Report may indicate that your rich results are valid, the availability of optional fixes, or that there are issues preventing your rich results from rendering properly.


When an optional fix is shown, the rich result will still render. However, implementing the optional fixes suggested in the page’s result information panel may help you add more information to your rich results.



An “Issues” status indicates that the given page’s structured data is missing one or more required fields and will not render properly. Again, accessing the page result information panel can reveal more actionable details—in the example below, the missing field is explicitly highlighted.



When a rich result is valid, you can open up the page result information panel to view the type of rich result that page is eligible for.




The rich results section whether the structured data applied to a page is valid, along with the rich result type the page is eligible for.




Note: By default, Wix adds preset structured data markups to some of your site’s pages.




Before you get started with the Wix Site Inspection tool




To get the most out of this tool, it’s important to be aware of the requirements and limitations associated with it. When using the Wix Site Inspection tool, keep in mind:




  • The Site Inspection tool displays information about the most recently indexed version of your site. This may not be the same as the current, live version of your site, as it takes Google time to crawl and index site changes.

  • Google has a scan limit of 2000 pages per day—if you exceed this limit, you’ll need to wait 24 hours before you can scan your site again.

  • It may take some time for Google to index changes on your site. If you see issues in the report that you've already addressed, you can ask Google to recrawl your pages.



Evaluate your technical SEO with Wix’s built-in tools




The Site Inspection tool can open up a world of potential optimizations, but even so, there are likely other aspects of your site’s technical health to monitor and improve. For those concerned about Google’s ability to efficiently crawl their sites, Wix’s bot log reports are an excellent place to start.





5 views0 comments

How to Fix the

NET::ERR_CERT_COMMON_NAME_INVALID

Error (9 Methods)

Downloaded on: 24 May 2022

Loading your website over HyperText Transfer Protocol Secure (HTTPS) is a key

cybersecurity best practice. However, if you don’t properly install your Secure Sockets Layer

(SSL) certificate, you can run into a number of errors, such as

NET::ERR_CERT_COMMON_NAME_INVALID.

Admittedly, solving this error can be a bit tricky, as there are many different reasons it may

appear in your browser. If you can narrow down the cause, resolving this SSL issue shouldn’t

take long at all.

In this article, we’ll explain what the NET::ERR_CERT_COMMON_NAME_INVALID error

means, and show you examples of what it looks like in various browsers. Then we’ll share

several methods you can use to fix it.

Let’s get started!

Understanding What Causes the

NET::ERR_CERT_COMMON_NAME_INVALID Error

Before we dive into what causes the NET::ERR_CERT_COMMON_NAME_INVALID error,

let’s break down the relevant terms. The ‘common name’ this error references is the domain

on which an SSL certificate is installed.

For example, if you have a website at mydomain.com, the common name on your SSL

certificate would be mydomain.com. So as the error message states, the root problem behind

NET::ERR_CERT_COMMON_NAME_INVALID is that the common name on your SSL

certificate is not valid for some reason.

Often, this means that the name on your certificate does not match the domain it’s installed

on. However, there are other scenarios that could lead to this message appearing in your

browser, including:

Your SSL certificate does not account for www versus non-www variations of your

domain.

You tried to switch your website to HTTPS without first installing an SSL certificate.

Your site has a self-signed SSL certificate installed and your browser does not

recognize it as valid or secure.

Your antivirus software is blocking your SSL connection.

A browser extension is interfering with your site’s SSL connection.

Your proxy settings are misconfigured.

Your browser cache or SSL state has become corrupted.

As you can see, many different factors can contribute to the

NET::ERR_CERT_COMMON_NAME_INVALID error. This can make it hard to pin down the

correct solution, but a little patience will go a long way towards helping you fix the problem.

NET::ERR_CERT_COMMON_NAME_INVALID Error

Variations

We’ll dive into the solutions to the NET::ERR_CERT_COMMON_NAME_INVALID error

shortly. First, however, you need to be able to recognize it in your browser.

Here’s what this problem looks like in the most popular clients on the web.

Google Chrome

Like many other HTTPS-related errors, Google Chrome indicates that there’s a common

name mismatch by showing a “Your connection is not private” warning:

— The NET::ERR_CERT_COMMON_NAME_INVALID error in Google Chrome

You will see the specific issue (NET::ERR_CERT_COMMON_NAME_INVALID) listed below

the main message. Users who see this screen may choose to proceed to your site anyway

using HTTP.

This message has the potential to scare away many prospective visitors.

Mozilla Firefox

Firefox presents a slightly different variation of the common name mismatch error. Under the

“Your connection is not secure” heading, it will tell you that the website you’re trying to reach

has not been configured properly, and recommend that you refrain from accessing it.

You may also see a message reading “Warning: Potential Security Risk Ahead”:

— A security risk warning in Mozilla Firefox

It may also display a more specific error message below, stating that the security certificate is

invalid and only configured to work with the listed domain names.

You’ll also see the “SSL_ERROR_BAD_CERT_DOMAIN” code.

Safari

In Safari, the corresponding error message reads, “Safari can’t verify the identity of the

website” or “Safari can’t open the page” followed by the domain you’re trying to reach.

It may also state that the site’s SSL certificate is invalid or that it was unable to establish a

secure connection:

— Error in Safari browser

When compared to other browsers, Safari’s common name mismatch error message is

somewhat vague.

If you’re seeing this error window, there are other SSL related problems that could also be

behind it, so make sure to pursue a variety of solutions.

Internet Explorer

Internet Explorer cuts right to chase, and informs you that “This site is not secure.” and

indicates an issue with the trustworthiness of the SSL certificate. This message may be

followed by a few different specifications:

— A security certificate warning in Internet Explorer

The one that indicates a problem equivalent to the

NET::ERR_CERT_COMMON_NAME_INVALID error in Chrome typically reads:

“The security certificate presented by this website was issued for a different

website’s address.”

It will also provide a few potential solutions for visitors, such as adding or removing “www”

from the URL they entered.

However, such fixes are only temporary. A persistent error could still harm your site’s

credibility and prevent you from growing your traffic, so it’s best to find the source of the issue

and resolve it quickly.

How to Fix the

NET::ERR_CERT_COMMON_NAME_INVALID Error (9

Methods)

As you now know, there are many possible causes of the

NET::ERR_CERT_COMMON_NAME_INVALID error. Therefore, there are also plenty of

potential fixes for it. Here are nine methods you can try to resolve this issue on your site.

1. Verify That Your SSL Certificate Is Correct

The most basic cause of the NET::ERR_CERT_COMMON_NAME_INVALID error is that your

site’s domain doesn’t match the common name listed on your SSL certificate. So, the first fix

you’ll want to try is viewing your certificate to determine if it’s been misconfigured.

Throughout this post, we’ll be showing examples of troubleshooting this error in Google

Chrome. However, other browsers should enable you to accomplish the same outcomes via

similar steps.

To get started, click on the Not Secure warning in the URL bar. In the menu that opens,

select Certificate (Invalid):

— Opening the certificate checker in Google Chrome

This will open a small window displaying the details of your SSL certificate:

— Checking the SSL certificate for a website in Google Chrome

The domain listed here should match the one you’re trying to reach. If not, you’ll know your

certificate is misconfigured.

The best solution is to remove the certificate from your site and install a new one.

Verifying Wildcard SSL Certificates

The NET::ERR_CERT_COMMON_NAME_INVALID error gets a little more complicated when

a wildcard SSL certificate is involved. This type of certificate is designed to encrypt data for

multiple subdomains.

As such, instead of having one common name listed on the certificate, a subdomain level

such as *.example.com is used. If you have a wildcard certificate installed and you are seeing

the NET::ERR_CERT_COMMON_NAME_INVALID error, it may mean that your certificate

does not cover the subdomain you’re trying to access.

Keep this in mind when verifying the SSL certificate in your browser. Also, note that wildcard

SSL certificates only secure one subdomain level. For instance, you would need separate

certificates for *.example.com and *.subdomain.example.com.

Verifying Subject Alternative Names (SAN) Certificates

A Subject Alternative Names (SAN) certificate can encrypt data for multiple domains that

point to the same site. This may include www and non-www variations, subdomains, and Top-

Level Domain (TLD) variations.

If the site you’re trying to access uses a SAN certificate, you may need to do some further

digging when verifying the SSL certificate in your browser.

In Chrome, click on Details in the certificate window:

— The Details tab of the certificate checker window in Google Chrome

Scroll down until you find the section labeled Extension Subject Alternative Name. Below it,

you should see a list of all the domains the certificate protects.

2. Check for Misconfigured Redirects

If you redirect your site from one domain to another and don’t install an SSL certificate on the

first domain, it can result in errors. For example, many SSL certificates don’t automatically

account for www and non-www versions of your site.

Let’s say you set up www.example.com to redirect to example.com. If you install your SSL

certificate on example.com but not on www.example.com, you might see the

NET::ERR_CERT_COMMON_NAME_INVALID error.

If you’re not sure whether your site is redirecting visitors in this way, you can check using

Redirect mapper:

— The Redirect mapper tool

This tool only checks for redirects between the HTTP and HTTPS versions of your site, as

well as between www and non-www versions.

If you find that redirects are interfering with your SSL certificate, there are a couple of

solutions you can try. One is to change the common name on the certificate to the correct

version of the domain.

You can also acquire another certificate for the domain you’re redirecting from or a SAN

certificate that covers both domains. For wildcard domains, you’ll need to list each subdomain

that you want to encrypt, rather than redirecting between them.

3. Make Sure Your WordPress Address and Site Address Match

It’s fairly easy to accidentally switch your site address to HTTPS without installing an SSL

certificate, especially in WordPress. Whether you thought you were implementing a security

best practice or were just poking around in your site’s settings, you may have inadvertently

caused the NET::ERR_CERT_COMMON_NAME_INVALID error.

Fixing this is fairly straightforward.

In your WordPress dashboard, navigate to Settings > General. There, make sure your

WordPress Address and Site Address match:

— Checking the WordPress Address and Site Address settings

Additionally, if these URLs use HTTPS and you do not have an SSL certificate installed,

change them to HTTP. Remember to save any edits you make.

If after making this switch the error persists, you may need to also change the addresses in

your database via phpMyAdmin.

You can access this program via your hosting account. Open your site’s database by clicking

on its name in the left-hand sidebar, and then access the wp_options table:

— Checking the siteurl and home rows in phpMyAdmin

Look for the siteurl and home rows. Edit the addresses as necessary and then check to see

if you can access your site.

4. Determine If Your Site Is Using a Self-Signed SSL Certificate

When you acquire an SSL certificate through Let’s Encrypt or another reputable source, it’s

signed by a recognized Certificate Authority (CA). Self-signed certificates are not backed by a

CA but are created by users.

Self-signed certificates are not as secure as those recognized by a CA. Some users find them

appealing because they’re free, but Let’s Encrypt supplies authorized SSL certificates at no

cost as well. With the exception of setting one up for internal server purposes or localhost use

, there’s really no reason to use a self-signed certificate.

Since they don’t offer the full protections that authorized certificates do, browsers generally

label sites using self-signed certificates as ‘not secure’. In some cases, this may lead to the

NET::ERR_CERT_COMMON_NAME_INVALID error.

You can check your certificate’s CA using the first method we described earlier in this post.

This data will be listed in the certificate information popup:

— Checking the CA for an SSL certificate in Google Chrome

If you believe your site uses a self-signed certificate and you are not a developer, the best

course of action is to contact whoever built your site for you and ask them to remove it. That

way, you can replace it with an authorized one.

If you installed a self-signed certificate intentionally, you can authenticate it with your browser

to get past the error. This process varies significantly depending on your browser and

Operating System and is generally more difficult than simply installing a Let’s Encrypt

certificate.

5. Clear Your SSL State and Browser Cache

If everything looks correct in your certificate’s configuration, but you’re still seeing the

NET::ERR_CERT_COMMON_NAME_INVALID error, you may need to clear your SSL state.

Browsers might cache SSL certificates to speed up loading times. If you just installed a new

certificate, you may still see an error message even though everything is fine.

Again, this process varies depending on your browser and OS. We’ll focus on Chrome for this

example but show you how to clear your SSL state on both Windows and macOS.

For Windows, open the Start menu and enter Internet Options. Select that same option

when it appears, and go to the Content tab within the Internet Options window. Now click on

the Clear SSL Slate button:

— Clearing your SSL state in Windows

On macOS, you’ll need to use the keychain manager to clear your SSL state. You can access

it in Chrome by going to Settings > Privacy and security > Manage certificates:

— Opening the Manage certificates settings in Chrome on macOS

Look for the certificate that was listed for the domain you’re trying to access. Right-click on it

and select Delete:

— Deleting certificate data using the macOS keychain manager.

You may be prompted to supply your user password.

Deleting the certificate here should clear your SSL state and resolve

NET::ERR_CERT_COMMON_NAME_INVALID (if a corrupted cache was the cause).

It’s also smart to clear your browser cache for good measure. In Chrome, this is as simple as

opening the settings menu and selecting More Tools > Clear Browsing Data:

— Clearing your browsing data

You can also navigate to your Privacy and security settings to specify which data you want

to clear. Just make sure to select Cached images and files from the list of options.

Check Out Our Video Guide to Clearing Your Browser Cache

6. Assess Your Proxy Settings

A proxy server is used to route web traffic to retain anonymity for clients or origin servers. If

your proxy settings are misconfigured, it can restrict your web access and result in a variety of

problems, including SSL errors.

In order to prevent such issues, you want to reset your proxy settings. This process varies

depending on if you use a Windows or a Mac computer.

Regardless of which OS you use, you can access your proxy settings via Google Chrome by

navigating to Settings > Advanced > System > Open your computer’s proxy settings:

— Opening proxy settings via Google Chrome

If you’re using Windows, this will open the Internet Properties window. Click on the

Connections tab, and then choose the LAN Settings button and select Automatically

detect settings:

— Automatically detecting your network settings

On macOS, this will open your Network settings window. Click on the Proxies tab and

select Automatic Proxy Configuration:

— Turning on Automatic Proxy Configuration for macOS

You can then try accessing your site again to see if the error is resolved.

7. Troubleshoot for a Browser Extension Conflict

Like WordPress plugins, browser extensions don’t always play nicely with one another.

Some such conflicts may interfere with your site’s HTTPS connection, resulting in various

errors.

To see if a browser extension might be causing the

NET::ERR_CERT_COMMON_NAME_INVALID error, open your site in an incognito window:

— An incognito window in Google Chrome

This will mitigate the effects of any extensions you have installed. If you can reach your site

just fine in incognito mode, then a browser extension is likely the source of your troubles.

In this case, the best solution is to disable your extensions one at a time to determine which is

causing the error. You can then remove the culprit to resolve the issue permanently.

8. Change Your Antivirus Software Settings

Similarly, antivirus software may prevent proper HTTPS connections. If you’re running such a

program on your computer, check its settings to see if HTTPS scanning is disabled. If so,

you’ll want to enable it.

In the event that you change this setting and the problem doesn’t go away, you may want to

consider disabling the software entirely. If this fixes the

NET::ERR_CERT_COMMON_NAME_INVALID error, then you can contact your antivirus

program’s support team for further assistance.

Of course, you don’t want to leave your antivirus software disabled for a significant period of

time, as this poses a security risk. So it’s best to turn it back on while waiting for a response

from support and follow their guidance on resolving the error while maintaining your

computer’s safety.

9. Update Your Browser and Operating System (OS)

An outdated OS may lead to errors while trying to access certain websites. For that reason,

it’s smart to ensure that you’re running the latest version of Windows, macOS, or Linux.

You’ll also want to verify that your browser is up-to-date. To do so in Chrome, open the

Settings menu, and then select Help > About Google Chrome:

— Opening Google Chrome’s About section

Here you can view your browser’s version and turn on automatic updates:

— Viewing your Google Chrome version

If Chrome is not up to date, opening this screen should cause an update to start

automatically.

Summary

When it comes to browser errors, NET::ERR_CERT_COMMON_NAME_INVALID is a tricky

one to fix. However, if you can narrow down what’s causing the problem, you can resolve it

quickly and preserve your site’s credibility with visitors.

As the very first steps to fixing this error, we suggest starting by checking your SSL certificate

in your browser and looking for any misconfigured redirects. If these don’t help, then start

taking a look at all other aspects we mentioned in this guide.



c08500cb9b12178780fd9d10e43e8c2c-net-err_cert_common_name_invalid
.pdf
Download PDF • 1.98MB

0 views0 comments
bottom of page