纠正问题的根源。
作为优秀的 SEO，我们知道我们应该尽一切努力确保只有一个域名解析到一个网站。目前没有办法阻止 AWS 添加公共 DNS 条目，解决此问题的一种方法是确保如果使用 AWS 子域访问 Web 服务器，则重定向到主域。下面是使用 Apache mod_rewrite 执行此操作的示例：
此修复立即阻止了
Googlebot 抓取我们的 amazonaws.com 子域名地址，这给我们的服 土耳其电话号码数据 务器带来了很大的负载，，数千个页面已经被编入索引。由于这些页面可能不会造成任何危害，所以我认为只需让 Google 找到所有 301 重定向并从索引中删除这些页面。于是我等待、等待、等待。一个月后，索引的页面数量（根据 site: 命令）完全相同。未从索引中删除任何页面。
去清理它。
为了帮助 Google，我决定使用网站管理员工具提交删除请求。我还暂时删除了 301 重定向并允许 Google 查看我网站的验证文件（显然它被重定向到我主域上的验证文件），然后将 301 重定向重新放回。我提交了删除整个网站的请求，但由于该域名未被 robots.txt 阻止，因此请求被拒绝。再说一次，我认为这非常愚蠢，因为整个子域都被重定向到正确的域。
因为我对删除请求不能按照我想要的方式进行感到有点恼火，所以我想再给谷歌 马特·谢尔曼 高级副总裁 营销总监 一个月的时间，看看它是否会获得 301 重定向。又过了至少一个月，索引中仍没有任何页面被删除。这证实了我的怀疑：Google 在查找网络链接图中不存在的内容的 301 重定向方面做得很差。我以前遇到过这种情况，我更改了 URL，更新了所有内部链接以指向新 URL，并重定向了旧 URL。 Google 似乎不会返回其索引并重新抓取其在标准网页抓取中未找到的页面以查看它们是否已被删除或重定向（或者如果它这样做了，它会非常缓慢地执行）。
由于法没有成功
我决定使用 robots.txt 文件来阻止 Google。这里的问题是，坦率地说，我不 但当我注意到 想编辑我的主要 robot.txt 来阻止机器人，因为这会阻止我的主域被抓取。相反，我创建了一个名为 robots-block.txt 的文件，其中包含常见的阻止指令：
用户代理：*
不允许：/
然后我将 .htaccess 文件中的重定向条目更改为如下内容：
这基本上意味着，如果请求的主机是ec2-123-456-789- 澳大利亚数据 且请求的路径是robots.txt，那么将提供 robot-block.txt 文件。这意味着我有一个与该子域不同的 robots.txt 文件。完成此操作后，我返回网站管理员工具，提交了网站删除请求，这次请求被接受了。 “瞧”，我的重复内容消失了！为了确保万无一失，我用实际的重定向命令替换了 robots.txt mod_rewrite，以确保任何真实用户都能被正确重定向。