网站iis日志中出现大量404，该怎么办

Posted 2023-03-28

建议有条件的朋友对错误目录和页面进行301永久重定向，而我是采取了404错误页面的方法来降低对新网站带来的影响：

　　一、制作404错误提示页
　　制作404页面在醒目位置要明确注明“访问的页面已经不存在，您可以返回×××网站首页进行浏览你所需要的内容”，并在这段说明中加入首页地址链接来引导用户，一方面可以降低用户流失，另一方面可以和搜索引擎蜘蛛对话，告诉蜘蛛这是一个错误的的地址。许多朋友将404错误页面跳转到首页，二老猫认为这是存在风险不可取的，会被搜索引擎误认为做弊导致首页降权。

　　二、404错误页的测试
　　页面制作好以后，命名为404.htm或者其它后辍传入网站根目录(由于个别虚拟空间要求不一样可详细查看空间说明和询问主机商)，上传完成后在虚拟主机管理面板上设置自定义404错误页路径。传上去后还没有完事，有更重要的工作，那就是测试404错误页面的有效性，许多网站提供“http状态查询”，输入一个不存在的页面和或目录然后检测，当返回状态码为404说明是有效的，如果不存在的路径返回状态码为200那就需要注意，说明你的设置无效或者你的主机自定义404错误页面有问题，需要联系主机商解决。下图为正确设置了404错误页面返回的状态码。

　　三、设置robots禁止抓取错误页面
　　对于一个功能完善和友好的新网站，404错误页面是必须的，但是我现在的情况光制作了404还不够。301定向太麻烦，后来想到了robots，这是网站与搜索引擎蜘蛛对话的一个重要文件，那我就在这个文件中告诉蜘蛛禁止抓取不存在的目录和网页。查看空间访问日志发现蜘蛛主要是抓取名为mynist目录下的文件，这个目录是以前旧网站的静态网页存放目录，弄清楚就好办了，在robots文件中添加如下语句Disallow:/mynist/，意思是禁止抓取此目录下的任何文件，再仔细查看日志，将不存在的目录和页面一一添加在robots文件中。百度站长俱乐部lee提到过，robots新添加的语句并不会立即生效需要过程的，正常情况下一周内生效，所以在修改后几天内蜘蛛仍然会抓取已禁止的页面是正常的。 参考技术A 1、首先检查出现404的原因是什么，先解决这些问题。
2、登录百度站长平台，将无法解决的404页面提交到站长平台。
3、持续更新你的内容，保证正常的收录。会慢慢恢复权重的！

如何分析iis日志

如果你的网站也不定时的出现连接超时，打开超慢的情况，而服务商又说没有问题，不妨跟着本文学着分析IIS日志，自己来解决问题。
IIS日志通常情况下存在于虚拟主机根目录下的logfiles文件夹(有些服务商是WebLog，不同的主机有不同的名称)中，按日期形成的txt文件或log.gz文件。它完整的记录着每一次网站的HTTP请求，包括200，404等。 参考技术A 虽然Log
Parser支持将解析的IIS日志以表格形式供人阅读，但是有时候我们需要再做一些细致分析时，可能会按不同的方式进行【多次】查询，
对于这种需求，如果每次查询都直接运行Log Parser，你会浪费很多时间。 幸运的是，Log
Parser支持将解析结果以多种格式导出（以下为帮助文档截图）：

在此，我建议选择输出格式为 SQL 。　　注意：这里的SQL并不是指SQLSERVER，而是指所有提供ODBC访问接口的数据库。　　我可以使用下面的命令将IIS日志导入到SQLSERVER中（说明：为了不影响页面宽度我将命令文本换行了）：
"C:\Program Files\Log Parser 2.2\logparser.exe"
"SELECT * FROM 'D:\Temp\u_ex130615.log' to MyMVC_WebLog" -i:IISW3C -o:SQL
-oConnString:"Driver=SQL Server;server=localhost\sqlexpress;database=MyTestDb;Integrated Security=SSPI" -createtable:ON
导入完成后，我们就可以用熟悉的SQLSERVER来做各种查询和统计分析了，例如下面的查询：
SELECT cip,csmethod,sport,csuristem,scstatus,scwin32status,scbytes,csbytes,timetaken
FROM dbo.MyMVC_WebLog
如果如下：

1.
IIS日志在将结果导出到SQLSERVER时，字段名中不符合标识符规范的字符将会删除。　　例如：c-ip 会变成 cip， s-port
会变成 sport 。　　2. IIS日志中记录的时间是UTC时间，而且把日期和时间分开了，导出到SQLSERVER时，会生成二个字段：

date, time这二个字段看起来很不舒服，对吧？　　我也很反感这个结果，下面来说说的二种解决方法：
1. 在SQLSERVER中增加一列，然后把UTC时间换成本地时区的时间，T-SQL脚本如下：
alter table MyMVC_WebLog add RequestTime datetime
goupdate MyMVC_WebLog set RequestTime=dateadd(hh,8,convert(varchar(10),date,120)
+ ' ' + convert(varchar(13),time,114))
2. 直接在导出IIS日志时，把时间转换过来，此时要修改命令：
"C:\Program Files\Log Parser 2.2\logparser.exe"
"SELECT TO_LOCALTIME(TO_TIMESTAMP(ADD(TO_STRING(date, 'yyyy-MM-dd '), TO_STRING(time, 'hh:mm:ss')),
'yyyy-MM-dd hh:mm:ss')) AS RequestTime, * FROM 'D:\Temp\u_ex130615.log' to MyMVC_WebLog2" -i:IISW3C -o:SQL
-oConnString:"Driver=SQL Server;server=localhost\sqlexpress;database=MyTestDb;Integrated Security=SSPI"-createtable:ON
再看这三列：
select RequestTime, date, time from MyMVC_WebLog2

这样处理后，你就可以直接把date, time这二列删除了（你也可以在导出IIS日志时忽略它们，但要明确指出每个字段名）。
IIS日志中的UTC时间问题就说到这里，但愿每个人都懂了~~~~~~~~~~~
IIS日志中的异常记录
IIS日志中记录了每个请求的信息，包括正常的响应请求和有异常的请求。
这里所说的【异常】与 .net framework 中的异常没有关系。　　对于一个ASP.NET程序来说，如果抛出一个未捕获异常，会记录到IIS日志中（500），但我所说的异常不仅限于此。
本文所说的异常可分为四个部分：　　1. （ASP.NET）程序抛出的未捕获异常，导致服务器产生500的响应输出。　　2. 404之类的请求资源不存在错误。　　3. 大于500的服务器错误，例如：502，503　　4. 系统错误或网络传输错误。
前三类异常可以用下面的查询获得：
select
scStatus, count(*) AS count, sum(timetaken * 1.0) /1000.0 AS
sum_timetaken_secondfrom MyMVC_WebLog with(nolock)group by scStatusorder
by 3 desc

IIS日志中有一列：sc-win32-status ，它记录了在处理请求过程中，发生的系统级别错误，例如网络传输错误。　　正常情况下，0 表示正常，出现非零值意味着出现了错误。我们可以这样统计这类错误：
declare
@recCount bigint;select @recCount = count(*) from MyMVC_WebLog
with(nolock)select scWin32Status, count(*) AS count, (count(*) * 100.0 /
@recCount) AS [percent]
from MyMVC_WebLog with(nolock)where scWin32Status > 0group by
scWin32Statusorder by 2 desc