Ошибка переадресации гугл

Такой вопрос это нужно сделать или стоит переадресация?

# BEGIN WP Rocket v3.8.5
# Use UTF-8 encoding for anything served text/plain or text/html
AddDefaultCharset UTF-8
# Force UTF-8 for a number of file formats
<IfModule mod_mime.c>
AddCharset UTF-8 .atom .css .js .json .rss .vtt .xml
</IfModule>
# FileETag None is not enough for every server.
<IfModule mod_headers.c>
Header unset ETag
</IfModule>
# Since we’re sending far-future expires, we don’t need ETags for static content.
# developer.yahoo.com/performance/rules.html#etags
FileETag None
<IfModule mod_alias.c>
<FilesMatch "\.(html|htm|rtf|rtx|txt|xsd|xsl|xml)$">
<IfModule mod_headers.c>
Header set X-Powered-By "WP Rocket/3.8.5"
Header unset Pragma
Header append Cache-Control "public"
Header unset Last-Modified
</IfModule>
</FilesMatch>
<FilesMatch "\.(css|htc|js|asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|json|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|otf|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|tif|tiff|ttf|ttc|wav|wma|wri|xla|xls|xlsx|xlt|xlw|zip)$">
<IfModule mod_headers.c>
Header unset Pragma
Header append Cache-Control "public"
</IfModule>
</FilesMatch>
</IfModule>
# Expires headers (for better cache control)
<IfModule mod_expires.c>
	ExpiresActive on
	ExpiresDefault                              "access plus 1 month"
	# cache.appcache needs re-requests in FF 3.6 (thanks Remy ~Introducing HTML5)
	ExpiresByType text/cache-manifest           "access plus 0 seconds"
	# Your document html
	ExpiresByType text/html                     "access plus 0 seconds"
	# Data
	ExpiresByType text/xml                      "access plus 0 seconds"
	ExpiresByType application/xml               "access plus 0 seconds"
	ExpiresByType application/json              "access plus 0 seconds"
	# Feed
	ExpiresByType application/rss+xml           "access plus 1 hour"
	ExpiresByType application/atom+xml          "access plus 1 hour"
	# Favicon (cannot be renamed)
	ExpiresByType image/x-icon                  "access plus 1 week"
	# Media: images, video, audio
	ExpiresByType image/gif                     "access plus 4 months"
	ExpiresByType image/png                     "access plus 4 months"
	ExpiresByType image/jpeg                    "access plus 4 months"
	ExpiresByType image/webp                    "access plus 4 months"
	ExpiresByType video/ogg                     "access plus 4 months"
	ExpiresByType audio/ogg                     "access plus 4 months"
	ExpiresByType video/mp4                     "access plus 4 months"
	ExpiresByType video/webm                    "access plus 4 months"
	# HTC files  (css3pie)
	ExpiresByType text/x-component              "access plus 1 month"
	# Webfonts
	ExpiresByType font/ttf                      "access plus 4 months"
	ExpiresByType font/otf                      "access plus 4 months"
	ExpiresByType font/woff                     "access plus 4 months"
	ExpiresByType font/woff2                    "access plus 4 months"
	ExpiresByType image/svg+xml                 "access plus 1 month"
	ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
	# CSS and JavaScript
	ExpiresByType text/css                      "access plus 1 year"
	ExpiresByType application/javascript        "access plus 1 year"
</IfModule>
# Gzip compression
<IfModule mod_deflate.c>
# Active compression
SetOutputFilter DEFLATE
# Force deflate for mangled headers
<IfModule mod_setenvif.c>
<IfModule mod_headers.c>
SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
# Don’t compress images and other uncompressible content
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png|rar|zip|exe|flv|mov|wma|mp3|avi|swf|mp?g|mp4|webm|webp|pdf)$ no-gzip dont-vary
</IfModule>
</IfModule>
# Compress all output labeled with one of the following MIME-types
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE application/atom+xml \
		                          application/javascript \
		                          application/json \
		                          application/rss+xml \
		                          application/vnd.ms-fontobject \
		                          application/x-font-ttf \
		                          application/xhtml+xml \
		                          application/xml \
		                          font/opentype \
		                          image/svg+xml \
		                          image/x-icon \
		                          text/css \
		                          text/html \
		                          text/plain \
		                          text/x-component \
		                          text/xml
</IfModule>
<IfModule mod_headers.c>
Header append Vary: Accept-Encoding
</IfModule>
</IfModule>
# END WP Rocket
# BEGIN WP Hide & Security Enhancer
<IfModule mod_rewrite.c> 
RewriteEngine On 
RewriteBase / 
#WriteCheckString:1614091674_63237
RewriteRule .* - [E=HTTP_MOD_REWRITE:On]
RewriteRule ^usasooju/(.+) /wp-content/themes/houzez/$1 [L,QSA]
RewriteRule ^xuthoalr/(.+) /wp-content/plugins/$1 [L,QSA]
RewriteRule ^oastoops/(.+) /wp-includes/$1 [L,QSA]
RewriteRule ^eglyroat/(.+) /wp-content/uploads/$1 [L,QSA]
RewriteRule ^eceeksyp.php /wp-comments-post.php [L,QSA]
RewriteRule ^fynoomog/(.+) /wp-content/$1 [L,QSA]
</IfModule> 
# END WP Hide & Security Enhancer
<IfModule mod_rewrite.c>
  RewriteEngine On
  # Check if browser supports WebP images
  RewriteCond %{HTTP_ACCEPT} image/webp
  # Check if WebP replacement image exists
  RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
  # Serve WebP image instead
  RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=REQUEST_image]
</IfModule>
<IfModule mod_headers.c>
  # Vary: Accept for all the requests to jpeg and png
  Header append Vary Accept env=REQUEST_image
</IfModule>
<IfModule mod_mime.c>
  AddType image/webp .webp
</IfModule>
# BEGIN WordPress
# Директивы (строки) между `BEGIN WordPress` и `END WordPress`
# созданы автоматически и подлежат изменению только через фильтры WordPress.
# Сделанные вручную изменения между этими маркерами будут перезаписаны.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
# MalCare WAF
<Files ".user.ini">
<IfModule mod_authz_core.c>
  Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
  Order deny,allow
  Deny from all
</IfModule>
</Files>
# END MalCare WAF
# BEGIN EXPIRES 
<IfModule mod_expires.c>
ExpiresActive On 
ExpiresDefault "access plus 6 month"
ExpiresByType text/css "access plus 6 month" 
ExpiresByType text/plain "access plus 6 month"
ExpiresByType image/gif "access plus 6 month"
ExpiresByType image/png "access plus 6 month" 
ExpiresByType image/jpeg "access plus 6 month" 
ExpiresByType application/x-javascript "access plus 6 month"
ExpiresByType application/javascript "access plus 6 month"
ExpiresByType application/x-icon "access plus 6 month" 
</IfModule>  
# END EXPIRES

“Redirect error” is a Google Search Console status. It means that bots didn’t get to the destination URL as a redirect you set up didn’t work, or they encountered an error on a URL level. It also indicates that the affected page wasn’t indexed.

Always treat the “Redirect error” pages as a priority – when left unattended, they may contribute to severe SEO issues like wasting your crawl budget or losing accumulated ranking signals.

Causes for “Redirect error”

If you see the “Redirect error” status in your Page indexing (Index Coverage) report, it means that:

• You set up a redirect to transfer both bots and users from one page to another URL,
• Googlebot received a 3xx redirect response code from your server,
• Googlebot wanted to follow your redirect, but it encountered an error, and as a result
• It didn’t get to your destination page within a given redirect.

Occasionally, “Redirect error” may result from Google’s problems. It happened last year when Google Search Console sent false redirect error notifications to its users.

However, in most cases, redirect errors derive from your website’s internal issues and lack of SEO expertise in implementing redirects.

Let’s take a closer look at what might have caused the “Redirect error” in your Google Search Console.

Too many redirects in a row

Imagine that URL A is the original page you want to redirect, and URL C is your destination page where you want both bots and users forward to.

But when for some reason, you set up more than one URL between URL A and URL C, then you’re creating a redirect chain.

And what you need to know is that, from the SEO perspective, redirect chains are dangerous, and you should avoid them.

Why? Because every additional page in a row requires using extra resources to get to the destination page. And due to its limited resources, Google may stop following your redirects. 

In other words, it indicates that a redirect chain is too long, so Googlebot won’t get to your final URL.

And when bots give up following redirects in a given chain, users are served an ERR_TOO_MANY_REDIRECTS error page and don’t get forwarded to the destination URL.

Although one additional page between URLs A and C may not look overwhelming, it happens that some websites have even 6 (or more!) redirects in one chain.

You may then ask, how many redirects in a row is too many?

John Mueller mentioned during one of the SEO Office Hours that Google follows up to 5 redirects simultaneously.

Moreover, according to Google’s official documentation, Googlebot can follow up to 10 pages in a redirect chain, but I would strongly advise you against testing it out.

As a rule of thumb, you should always aim to redirect the original page to the destination URL directly, so in my example case above, it’d be from URL A to C.

And if you also want URL B to be redirected, set up a separate redirect from URL B to C.

Note that as long as you’re following this rule, there’s no limit to the number of single redirects coming from a given page.

Also, remember that everything gets even more complicated when dealing with different types of redirects.

For example, you should watch out for using 301 and 302 redirects in one redirect chain. As you should use 301 and 302 for different cases, it may be difficult for Google to interpret if you want your pages to be temporarily or permanently redirected.

You shouldn’t risk sending mixed signals to Google if you care about your website’s SEO.

Redirect loops

A redirect loop is when you set up a redirect from URL A to B but then forward bots from URL B again to URL A. It’s a straightforward way to get Googlebot dizzy.

And when Googlebot gets forwarded over and over again, it means that:

• In fact, the redirection from URL A to B doesn’t work, and
• Users never get to the final page within such an endless redirect, so they see the ERR_TOO_MANY_REDIRECTS error page.

Redirect loops are another example of poor redirect configuration and implementation on your website.

Although often confused with each ofter, redirect chains and loops differ significantly. In the case of redirect chains, users may sometimes get to a live URL. In turn, redirect loops never allow both bots and users to access the final page. 

There’s nothing like a minimum number of loops you can make – you should avoid them at all costs.

Remember that the perfect scenario is always when you can make Googlebot get to the final page in one ‘hop.’

Incorrect redirect URLs

Your redirect may also not work due to errors on a URL level, e.g., mistakes in the URL structure.

It may happen when the target URL is unintentionally malformed, e.g., includes ‘htttp’ instead of ‘http’ or ‘wwww’ instead of ‘www.’

Another example is when the redirect URL exceeds the maximum URL length. It may happen when adding multiple URLs to a redirect loop and resulting in, e.g., heavily parameterized URLs.

It doesn’t necessarily mean filtering or query parameters are harmful by default. They may be beneficial on eCommerce websites when configured correctly.

But as a rule of thumb, the shorter the URL length, the better. Follow the best practices for creating an SEO-friendly URL structure.

And to avoid “Redirect error,” always ensure Google doesn’t struggle with accessing your final URL.

In general, if the destination page doesn’t respond with the 200 HTTP response code, Googlebot will consider it invalid and won’t schedule its rendering and indexing.

So although such mistakes may seem rare and minor, you shouldn’t let them arise on your website.

And in the case when the target page responds with a different response code, like a 404, you should look for it within the corresponding status in the Page indexing (Index Coverage) report.

How to fix “Redirect error”

If you want to fix “Redirect error” in Google Search Console, you need to:

• Identify why your redirect didn’t work, and then
• Ensure that the original page directly forwards bots and users to the destination URL.

When properly fixed and redirected, the status of the affected URL should change to “Page with redirect” in the Page indexing (Index Coverage) report.

But addressing this issue may require a more detailed approach.

That’s why, without further ado, let’s dive into how to fix the “Redirect error” issue step-by-step.

Analyze the list of the affected pages in Google Search Console

First, browse the list of the affected pages in the Page indexing (Index Coverage) report to assess the scale of the problem or look for any patterns in the affected URLs.

If you suspect that your website may struggle with redirect chains or loops, here’s when I need to warn you.

The report will show you only the URL that initiated a given redirect. For more information on possible redirect chains or loops, you need to look beyond Google Search Console. I describe how to do it in the next section.

Another aspect you need to examine in the Page indexing (Index Coverage) report is if your sitemap file doesn’t include any “Redirect error” pages. 

To do this, enter the status page and, using the dropdown menu in the upper left corner of the report, filter out the affected URLs to ‘All submitted pages.’

Considering that you don’t want the affected URL to be indexed, you shouldn’t find any pages here.

One of the best practices is to update your XML sitemaps every time you set up a redirect. Remember that your sitemap file should only include pages you want to get indexed and which respond with the 200 status code.

It’s also when you should consider whether you want the affected page to be redirected.

If you use a 301 redirect, users won’t see the original URL, as they can only access the destination page. But when you want users to access both of these pages and indicate that one is more critical for you, you should consider removing the redirection method and using the canonical tag.

Read how you can benefit from canonical tags and how they differ from 301 redirects in our guide to canonical tags.

Fix redirect chains and loops

As you already know, although beneficial when reporting the “Redirect error” issues, the Page indexing (Index Coverage) report won’t show you what triggered them.

One option for a redirection audit I take advantage of is installing an extension to your browser and monitoring pages while browsing your website.

My tool of choice is Link Redirect Trace, but I recommend you to check out Redirect Path from Ayima (for Google Chrome) or HEADMasterSEO (if you prefer desktop tools.)

When you enter the original page, the Link Redirect Trace tool outlines all URLs included in the chain specifying the HTTP response codes for each page and where they redirect to.

The tool also shows you the number of redirects in one chain. It might be helpful when dealing with long chains, as in the example above – the tool identified 10 (!) redirects in one row.

A thorough analysis of URLs can also help you navigate the redirect loop issues. It was the case for the example I analyzed above – the last URL in the chain doesn’t respond with a 200 response code, but it forwards bots to the original page.

However, manually checking for chains and loops may not be a perfect approach if you’re dealing with a large website.

Here’s when you should perform a site crawl to ensure you don’t miss any redirects. To do this, you should use an SEO crawler like, e.g., Screaming Frog.

Create a redirection plan

To face your “Redirect error” issues, you need a proper plan of action to ensure you have control over your redirects. 

Start with creating a spreadsheet that outlines the list of original pages you want to redirect and their destination URLs.

Follow the same pattern when planning to implement new redirects on your website. It’s also a crucial step to keep track of all the planned changes when preparing for website migration.

Apart from that, remember that when redirecting, you need to think about SEO at each step of the process. To make it easier, I prepared a list of best practices for fixing and implementing your redirects: 

Almost done. Now, check if your “Redirect error” issues have been resolved in Google Search Console, and you can enjoy the traffic moving to your new destination URLs.

However, remember that your changes may not be immediately visible in Google Search Console. Google will pick up your updated redirects depending on how often and quickly Googlebot crawls your website.

In the case of a small website, you can manually check if your redirects work as you intended.

All you have to do is type your original URL and use one of the browser extensions I recommended. This way, you can see if you get forwarded to the destination page in your browser. 

But when you’re managing a large website, I understand how challenging it may be to implement and monitor your redirects. It’s also because the bigger a website is, the more SEO aspects you need to think about.

Key takeaways

1. In most cases, “Redirect error” issues are self-induced. Remember to follow these best practices when implementing redirects:
   • avoid creating redirect chains and loops, and
   • double-check for bad URLs or empty pages that may stop bots and users from getting to your destination content.
2. Optimizing your redirects is crucial to perform a healthy website migration. Whether changing your URL structure or merging your content, correctly implemented redirects will help you enhance user experience and transfer your accumulated PageRank.
3. The Page indexing (Index Coverage) report in Google Search Console will only give you an insight into your redirect errors. For detailed research of your problems, perform a full site crawl or use tools like Link Redirect Trace.
4. The larger your website is, the more complex the debugging process may be. Contact us for a thorough technical SEO analysis of your website to ensure your redirects work as you intended.

На этой странице описывается, как коды статуса HTTP, а также ошибки сети и DNS отражаются на позиции вашего контента в Google Поиске. Мы поговорим о 20 наиболее распространенных кодах статуса, которые обнаруживает на веб-страницах робот Googlebot, а также о самых частых ошибках сети и DNS. Такие редко встречающиеся коды, как 418 (I'm a teapot), в этой статье не рассматриваются. Все перечисленные на этой странице проблемы приводят к появлению ошибки или предупреждения в отчете об индексировании страниц, доступном в Search Console.

Коды статуса HTTP

Когда сервер, на котором размещен сайт, получает запрос клиента (например, браузера или поискового робота), в ответ он отправляет код статуса HTTP. Каждый такой код имеет свое значение, но многие из них предполагают, что запрос будет обрабатываться одинаково. Например, о переадресации могут сигнализировать несколько разных кодов.

Сообщения об ошибке, генерируемые в Search Console, относятся к кодам статуса в диапазоне 4xx–5xx, а также к неудачной переадресации (3xx). Если в ответе сервера указан код статуса 2xx, полученный контент может быть проиндексирован.

В таблице ниже приведены коды статуса HTTP, с которыми чаще всего сталкивается робот Googlebot, и пояснения о том, как обрабатывается каждый такой код.

Ошибки soft 404

Ошибкой soft 404 называется ситуация, когда посетитель веб-страницы видит сообщение о том, что ее не существует, при этом браузер получает ответ с кодом статуса 200 (success). Этот код означает «Успешно». В некоторых случаях открывается страница, на которой нет основного или вообще никакого контента.

Такие страницы создаются веб-сервером, где размещен сайт, системой управления контентом или браузером пользователя. Причины могут быть разными. Пример:

• Отсутствие файла SSI
• Ошибка при обращении к базе данных
• Пустая внутренняя страница результатов поиска
• Незагруженный или отсутствующий по другой причине файл JavaScript

Мы не рекомендуем возвращать код статуса 200 (success), а затем выводить сообщение об ошибке или указывать на наличие ошибки на странице. Пользователи могут подумать, что попали на действующую страницу, но после этого увидят сообщение об ошибке. Подобные страницы исключаются из Google Поиска.

Если алгоритмы Google по контенту страницы определяют, что она содержит сообщение об ошибке, то в отчете об индексировании страниц этого сайта в Search Console будет указана ложная ошибка soft 404.

Порядок исправления ошибок soft 404

Есть разные способы устранения ошибок soft 404 в зависимости от состояния сайта и от желаемого результата:

• Страница и ее контент больше не доступны
• Страница или ее контент были перенесены
• Страница и ее контент по-прежнему существуют

Подумайте, какое решение будет оптимальным для ваших пользователей.

Страница и ее контент больше не доступны

Если страница удалена и для нее нет замены на вашем сайте с аналогичным контентом, нужно отправлять ответ с кодом статуса 404 (not found) или 410 (gone). Эти коды статуса сообщают поисковым системам, что страницы не существует, а контент не нужно индексировать.

Если у вас есть доступ к файлам конфигурации вашего сервера, страницы с сообщениями об ошибках можно сделать полезными для пользователей. Например, на такой странице 404 вы можете разместить функции, призванные помогать посетителям в поиске нужной информации, или полезный контент, который удержит их на вашем ресурсе. Вот несколько советов по созданию полезной страницы 404:

• Пользователям должно быть понятно, что запрашиваемая страница недоступна. Текст сообщения должен быть вежливым и привлекающим внимание.
• Страница 404 должна быть выполнена в том же стиле (включая элементы навигации), что и основной сайт.
• Разместите на странице ссылки на самые популярные статьи или записи блога, а также на главную страницу.
• Дайте пользователям возможность сообщать о неработающих ссылках.

Полезные страницы 404 создаются исключительно для удобства пользователей. Поисковые системы игнорируют такие страницы, поэтому рекомендуем возвращать для этих страниц код статуса HTTP 404, чтобы они не индексировались.

Страница или ее контент перемещены

Если страница перенесена или у нее есть замена, отправляйте ответ с кодом 301 (permanent redirect), чтобы перенаправлять пользователей. Посетителям сайта это не помешает, а поисковые системы узнают новое расположение страницы. Чтобы узнать, правильный ли код ответа отправляется при открытии страницы, используйте инструмент проверки URL.

Страница и ее контент по-прежнему существуют

Если нормально работающая страница вызвала ошибку soft 404, вероятно, она не была корректно загружена роботом Googlebot, во время отрисовки не были доступны важные ресурсы или показывалось заметное сообщение об ошибке. Проанализируйте отрисованный контент и код ответа HTTP с помощью инструмента проверки URL. Если на обработанной странице нет или очень мало контента или он вызывает ошибку, ошибка soft 404 может быть обусловлена тем, что страница содержит ресурсы (например, изображения, скрипты и прочие нетекстовые элементы), которые не удается загрузить.
Возможные причины проблем с загрузкой – блокировка доступа в файле robots.txt, слишком большое количество ресурсов или слишком большой их размер, а также любые ошибки сервера.

Ошибки сети и DNS

Ошибки сети и DNS отрицательно влияют на показ URL в результатах поиска Google.
Робот Googlebot интерпретирует тайм-ауты сети, факты сброса подключения и ошибки DNS так же, как и ошибки серверов 5xx. В случае сетевых ошибок сканирование начинает постепенно замедляться, поскольку сетевая ошибка означает, что сервер может не справиться с нагрузкой. Так как роботы Googlebot не смогли получить доступ к серверу, на котором размещен сайт, значит, им не удалось извлечь контент. В результате Google не может проиндексировать ранее просканированные URL, а недоступные нашим роботам URL, которые уже были проиндексированы, будут удалены из индекса Google в течение нескольких дней. Search Console может создавать сообщения о каждой возникающей ошибке.

Ошибки отладки сети

Эти ошибки возникают до того, как Google начинает сканирование URL, или во время этого процесса.
Поскольку они зачастую уже присутствуют до того, как сервер возвращает ответ, то из-за отсутствия кода статуса диагностика этих ошибок может вызывать трудности. Чтобы отладить ошибки тайм-аута и сброса подключения, выполните следующие действия:

• Проверьте настройки брандмауэра и записи в журнале. У вас может быть задано слишком общее правило блокировки. Нужно, чтобы ни одно правило брандмауэра не блокировало IP-адреса робота Googlebot.
• Проанализируйте сетевой трафик с помощью таких инструментов как tcpdump и Wireshark. Они помогут вам найти в пакетах TCP аномалии, относящиеся к определенному сетевому компоненту или модулю сервера.
• Если вы не можете найти ничего подозрительного, обратитесь к своему хостинг-провайдеру.

Ошибка может относиться к любому серверному компоненту, который обрабатывает сетевой трафик. Возможно, что перегруженные интерфейсы сети не могут передавать пакеты, что приводит к тайм-аутам (невозможности установить подключение) и сбросу подключений (отправляется пакет RST, поскольку порт был закрыт по ошибке).

Устранение ошибок DNS

Ошибки DNS чаще всего вызваны неправильной конфигурацией, но могут также возникать из-за правил брандмауэра, которые блокируют DNS-запросы робота Googlebot. Чтобы устранить ошибки DNS, выполните следующие действия:

• Проверьте правила брандмауэра. Нужно, чтобы ни одно правило не блокировало IP-адреса Google и чтобы были разрешены запросы как по протоколу UDP, так и по протоколу TCP.
• Проверьте записи DNS. Убедитесь, что записи A и CNAME ведут на правильные IP-адреса и имена хостов. Пример:

  dig +nocmd example.com a +noall +answer

  dig +nocmd www.example.com cname +noall +answer

• Убедитесь, что все ваши DNS-серверы указывают на правильные IP-адреса вашего сайта. Пример:

  dig +nocmd example.com ns +noall +answer
  example.com.    86400  IN  NS  a.iana-servers.net.
  example.com.    86400  IN  NS  b.iana-servers.net.
  dig +nocmd @a.iana-servers.net example.com +noall +answer
  example.com.    86400  IN  A  93.184.216.34
  dig +nocmd @b.iana-servers.net example.com +noall +answer
  ...

• Если вы внесли изменения в конфигурацию DNS в течение последних 72 часов, на их применение во всей сети DNS может потребоваться некоторое время. Чтобы ускорить внедрение новых настроек, вы можете очистить общедоступный кеш DNS.
• Если вы используете собственный DNS-сервер, убедитесь, что он исправен и не перегружен.