刚好之前帮客户处理过类似的Episerver多品牌站点维护场景，结合你用Azure Web App+流量管理器的架构，这里有两个靠谱的方案，能帮你实现「显示对应品牌维护页+返回503状态码」的需求，完全避开返回200的SEO坑：

方案一：单站点下用Rewrite+服务器变量（配置简洁，推荐） #

不需要拆分多个虚拟主机，在维护Web App的主web.config里就能搞定。核心思路是：根据访问的主机头匹配对应的维护页，同时强制把响应状态码改成503——这样浏览器显示正确的品牌维护内容，搜索引擎拿到的也是合规的503状态。

直接上配置片段（web.config里的system.webServer部分）：

<system.webServer>
  <!-- 先配置全局503错误映射，后续重写会动态指向对应页面 -->
  <httpErrors errorMode="Custom" existingResponse="Replace">
    <remove statusCode="503" subStatusCode="-1" />
    <error statusCode="503" path="/default-maintenance.html" responseMode="File" />
  </httpErrors>

  <rewrite>
    <rules>
      <!-- Site1的维护规则：匹配mysite域名 -->
      <rule name="Site1_Maintenance_503" stopProcessing="true">
        <match url=".*" />
        <conditions>
          <add input="{HTTP_HOST}" pattern="^mysite\.com$" />
        </conditions>
        <action type="Rewrite" url="/site1.html" />
        <!-- 强制设置响应状态为503 -->
        <serverVariables>
          <set name="RESPONSE_STATUS" value="503" />
          <set name="RESPONSE_STATUS_DESCRIPTION" value="Down for scheduled maintenance" />
        </serverVariables>
      </rule>

      <!-- Site2的维护规则：匹配myothersite域名 -->
      <rule name="Site2_Maintenance_503" stopProcessing="true">
        <match url=".*" />
        <conditions>
          <add input="{HTTP_HOST}" pattern="^myothersite\.com$" />
        </conditions>
        <action type="Rewrite" url="/site2.html" />
        <serverVariables>
          <set name="RESPONSE_STATUS" value="503" />
          <set name="RESPONSE_STATUS_DESCRIPTION" value="Down for scheduled maintenance" />
        </serverVariables>
      </rule>

      <!-- Site3的维护规则，依葫芦画瓢 -->
      <rule name="Site3_Maintenance_503" stopProcessing="true">
        <match url=".*" />
        <conditions>
          <add input="{HTTP_HOST}" pattern="^thirdsite\.com$" />
        </conditions>
        <action type="Rewrite" url="/site3.html" />
        <serverVariables>
          <set name="RESPONSE_STATUS" value="503" />
          <set name="RESPONSE_STATUS_DESCRIPTION" value="Down for scheduled maintenance" />
        </serverVariables>
      </rule>
    </rules>
  </rewrite>
</system.webServer>

重要提醒：
要让服务器变量生效，得在IIS里开权限——进入维护Web App的IIS管理器（可以通过Azure门户的「高级工具」→「Kudu」→「Debug console」→「CMD」，然后打开IIS管理器），找到站点的「URL重写」→「查看服务器变量」，添加RESPONSE_STATUS和RESPONSE_STATUS_DESCRIPTION这两个变量，允许修改它们。

方案二：拆分多虚拟主机（配置隔离性好） #

如果你们团队希望每个品牌的维护配置完全独立，不想互相影响，可以在Azure Web App里给每个品牌配单独的虚拟站点：

第一步：Azure端配置 #

1. 先在Web App的「自定义域名」里添加所有品牌的域名（mysite.com、myothersite.com等）
2. 到「配置」→「路径映射」，给每个品牌加一个虚拟应用（比如/site1对应物理路径/site1，里面放site1.html）

第二步：每个虚拟站点的独立web.config #

每个虚拟站点的web.config可以单独写，比如/site1的web.config：

<configuration>
  <system.webServer>
    <!-- 直接把503错误指向当前站点的维护页 -->
    <httpErrors errorMode="Custom" existingResponse="Replace">
      <remove statusCode="503" subStatusCode="-1" />
      <error statusCode="503" path="/site1.html" responseMode="File" />
    </httpErrors>

    <rewrite>
      <rules>
        <!-- 所有请求都返回503 -->
        <rule name="Return_503_All_Requests" stopProcessing="true">
          <match url=".*" />
          <action type="CustomResponse" statusCode="503" subStatusCode="0" statusReason="Site Unavailable" statusDescription="Down for scheduled maintenance" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

这样每个品牌的域名访问时，会触发对应虚拟站点的配置，返回503+对应维护页，完全隔离，后续改某个品牌的维护内容也不会影响其他品牌。

最后必看的细节 #

• 测试的时候一定要用curl -I https://yourdomain.com看响应头，确认状态码是503，别偷懒只看页面
• 维护Web App和生产站点完全独立，切换全靠流量管理器，生产环境不需要改任何配置，非常安全
• 绝对绝对别返回200，不然Google会把你的维护页当成正常页面索引，等你切回生产后还会留着缓存，SEO坑大了

内容的提问来源于stack exchange，提问作者John Little