wiki.js 这个系统好用则好用，但开发力量十分薄弱并且作者似乎在死命憋 v3 版本大招，v2 基本上只有很基本的安全维护了，例如SEO就没有sitemap功能。
最近，有人做了个wikijs-seo-tools项目，以外挂形式补上了这个功能。
按原项目说明，克隆仓库并build这个极小的docker镜像。如果有网络不方便，参看为 docker 的 pull/build 动作设置代理.
然后，在wiki.js管理面板的API这里，新建一个key，如果之前没有在用API，注意检查API总开关是否打开。
wiki.js 的无权限 API 好像总是开着的，这个开关只控制需要
key的那些API
在wikijs-seo-tools的docker-compose.yaml文件中设置：
version: '3.8'
services:
sitemap-service:
build: .
ports:
- "8000:8000"
environment:
- WIKIJS_BASE_URL=https://example.com
- WIKIJS_API_URL=https://example.com/graphql
- WIKIJS_API_TOKEN=your-api-token
随后，curl http://127.0.0.1:8000/sitemap看是否有正确的xml输出。
显然，上面的xml是不会自动挂到 Google 上去的。这里必须加一个反向代理，或者自己去改 wiki.js 的服务文件——如果是docker的话会极端麻烦。
我这边本来就套着caddy用来自动申请SSL，所以十分简单，在主站的反向代理前面加两条判断就好：
www.weiran.ink {
tls xxx@xxx.com
......
handle /sitemap.xml {
rewrite * /sitemap
reverse_proxy localhost:2813
}
handle /sitemap {
reverse_proxy localhost:2813
}
handle /timeline {
reverse_proxy localhost:2813
}
reverse_proxy localhost:2812
}
实际上，响应哪个地址并不是太重要。Google Search Console和Bing Webmasters都可以在通过认证域名所属权之后获得搜索控制权限，然后自定义网站地图的实际地址，理论上你写成wzdt.xml应该也是可以提交的。
这里加了三条前置判断。sitemap那两条是同时响应https://www.weiran.ink/sitemap和https://www.weiran.ink/sitemap.xml这两种样式的sitemap抓取，timeline是wikijs-seo-tools的附加功能，没查到哪些搜索引擎会要这个，反正放在那里也不多。
2813是我这边的wikijs-seo-tools服务端口，2812则是主站后端。这样一来，就通过反向代理把两个站捏在一起了。