售后附件上传页不要写进sitemap

售后让客户补传铭牌照片和故障视频，技术把上传页做成一个带客户编号的地址。几天后，市场人员在搜索结果里看到相同编号，sitemap 里也多了几条上传链接。售后附件上传页要能用，但不能按普通内容页交给搜索引擎。

入口页和上传地址要分开

官网可以保留一个稳定说明页，讲清客户需要准备设备铭牌、故障现象、拍摄时间、运行工况和联系人。真正的上传地址应由售后工单生成，带upload_token、ticket_no、expire_time和allowed_file_types，过期后返回提示页，不能继续收文件。

稳定说明页可以进入 sitemap，临时上传页不进入。若上传地址包含客户编号、订单号或令牌，页面头部要加 noindex，响应头也可补 X-Robots-Tag: noindex。类似受控资料的临时地址处理，可参考受控图纸下载的稳定页和临时文件地址划分。

入口页还要写清资料边界。客户可以看到文件大小、格式、有效期和售后工单编号，但不能看到其他客户上传记录。技术人员给入口页保留固定 canonical，给临时上传页返回独立状态码和过期提示，避免搜索系统把两类页面当成同一批内容。

附件字段要服务售后判断

售后补附件不是只收一个文件。表单字段要记录machine_model、serial_no、fault_time、file_role、uploader_name和service_owner。file_role至少区分nameplate、fault_photo、running_video、test_record和purchase_proof。售后负责人看字段就能判断附件是否够用，不用反复追问客户。

大图纸或视频上传失败时，页面要把状态写回工单。客户看到“提交成功”不代表售后收到全部文件，后台还要检查file_size、hash、virus_scan_status和storage_path。客户上传图纸丢失的排查方式，可对照大附件提交成功但销售看不到的检查方法。

文件名也要做一次整理。客户常把照片命名为IMG_001或维修视频，售后系统应保存original_name，同时生成internal_file_name，例如ticket-2407-serial-plate-01.webp。公开页面不展示原文件名，内部记录保留上传时间、审核人和是否可用于案例复盘。

sitemap只保留可公开判断的页面

资料负责人重建 sitemap 时，要排除/upload/、/attachment/、含token的URL、带ticket_no的URL和表单提交结果页。若站点程序会自动收集新地址，发布脚本要按 canonical、自引用、无参数、无 noindex 四个条件筛选，再写入 sitemap。

日志里也要能分清来源。客户从说明页进入上传页时，记录referrer_page和ticket_no；售后人员从后台补开入口时，记录operator和reason。以后检查异常抓取，技术人员能判断地址是客户触发、内部补发，还是程序误把临时页当成内容页。

表单成功页被收录会暴露客户编号，售后上传页也有同样风险。已有成功页风险可参考表单成功页被收录后的客户编号暴露问题。本篇的复查重点是上传入口和临时地址，不处理普通询盘确认邮件。

如果程序必须让客户刷新上传状态，状态页也不应写进 sitemap。页面只显示当前工单的附件数量、待审核状态和下一步联系人，不输出可下载的真实文件地址。客户需要补传时，系统重新生成短时令牌，并记录是谁重新打开了入口。

发布后要查真实抓取边界

不能直接判断的情况要交给技术负责人：上传页由第三方表单系统生成，文件存储在对象存储，或 CDN 会缓存带令牌的地址。售后负责人只确认业务字段和保管期限，技术负责人确认 noindex、robots、canonical、缓存时间和访问权限。

每月复查一次 sitemap 和服务器日志。抽查最近生成的上传链接，确认它们没有进入 sitemap，公开访问不会显示客户资料，过期链接不能下载附件，售后工单里能看到上传人、文件角色和审核状态。这样客户能补齐售后判断所需资料，搜索引擎只看到公开说明页。