When we get to managing multiple replicates of content for Swift.org, one of the pieces we'll absolutely want to sort out is a definitive choice on "which version is canonical", and including that within the HTML output that's served for the static content.
The relevant tag is included in HTML's <head> tags, using the form: <link rel="canonical">
The gist and impact, particularly from search engines, is that replicated content that either doesn't have such a tag, or doesn't agree on that tag, treated replicated content as potentially spam, and the indexing engines may simply directly "de-list" the content from their index.
This will have a broad effect on any replicated content when we have versioned copies of the Swift.org documentation collection, and perhaps may be hitting us even earlier, with some content replicated between developer.apple.com and what we're including in the combined documentation to host at docs.swift.org.
This may be a DocC feature request, or something that we have to enable post-processing to inject into the relevant HTML of the various pages, and we'll want to make sure to keep this coordinated with any documentation hosting for relevant libraries on Swift Package Index as well.
/cc @daveverwer
When we get to managing multiple replicates of content for Swift.org, one of the pieces we'll absolutely want to sort out is a definitive choice on "which version is canonical", and including that within the HTML output that's served for the static content.
The relevant tag is included in HTML's
<head>tags, using the form:<link rel="canonical">The gist and impact, particularly from search engines, is that replicated content that either doesn't have such a tag, or doesn't agree on that tag, treated replicated content as potentially spam, and the indexing engines may simply directly "de-list" the content from their index.
This will have a broad effect on any replicated content when we have versioned copies of the Swift.org documentation collection, and perhaps may be hitting us even earlier, with some content replicated between developer.apple.com and what we're including in the combined documentation to host at docs.swift.org.
This may be a DocC feature request, or something that we have to enable post-processing to inject into the relevant HTML of the various pages, and we'll want to make sure to keep this coordinated with any documentation hosting for relevant libraries on Swift Package Index as well.
/cc @daveverwer