diff --git a/content/_data/sidebar.json b/content/_data/sidebar.json
index 22196f636d..733689d93a 100644
--- a/content/_data/sidebar.json
+++ b/content/_data/sidebar.json
@@ -350,10 +350,6 @@
             {
               "title": "Cross Browser Testing",
               "slug": "cross-browser-testing"
-            },
-            {
-              "title": "Web Security",
-              "slug": "web-security"
             }
           ]
         },
@@ -757,10 +753,6 @@
               "title": "root",
               "slug": "root"
             },
-            {
-              "title": "route",
-              "slug": "route"
-            },
             {
               "title": "screenshot",
               "slug": "screenshot"
@@ -781,10 +773,6 @@
               "title": "selectFile",
               "slug": "selectfile"
             },
-            {
-              "title": "server",
-              "slug": "server"
-            },
             {
               "title": "session",
               "slug": "session"
@@ -941,10 +929,6 @@
               "title": "SelectorPlayground",
               "slug": "selector-playground-api"
             },
-            {
-              "title": "Server",
-              "slug": "cypress-server"
-            },
             {
               "title": "arch",
               "slug": "arch"
diff --git a/content/api/commands/intercept.md b/content/api/commands/intercept.md
index 73bac98f2f..bcef84fa4d 100644
--- a/content/api/commands/intercept.md
+++ b/content/api/commands/intercept.md
@@ -11,13 +11,6 @@ Spy and stub network requests and responses.
 
 </Alert>
 
-<Alert type="bolt">
-
-`cy.intercept()` is the successor to `cy.route()` as of Cypress 6.0.0. See
-[Comparison to `cy.route`](#Comparison-to-cy-route).
-
-</Alert>
-
 <Alert type="warning">
 
 All intercepts are automatically cleared before every test.
@@ -1486,16 +1479,6 @@ Cypress.minimatch('http://localhost/users?_limit=3', '**/users?_limit=+(3|5)', {
 // true (plus debug messages)
 ```
 
-## Comparison to `cy.route()`
-
-Unlike [cy.route()](/api/commands/route), `cy.intercept()`:
-
-- can intercept all types of network requests including Fetch API, page loads,
-  XMLHttpRequests, resource loads, etc.
-- does not require calling [cy.server()](/api/commands/server) before use - in
-  fact, `cy.server()` does not influence `cy.intercept()` at all.
-- does not have method set to `GET` by default, but intercepts `*` methods.
-
 ## `cy.intercept()` and request caching
 
 `cy.intercept()` intercepts requests at the network layer. This can cause
@@ -1597,7 +1580,6 @@ information about the request and response to the console:
 - [Network Requests Guide](/guides/guides/network-requests)
 - [Cypress Example Recipes](https://github.com/cypress-io/cypress-example-recipes#stubbing-and-spying)
 - [Kitchen Sink Examples](https://github.com/cypress-io/cypress-example-kitchensink/blob/master/cypress/integration/2-advanced-examples/network_requests.spec.js)
-- [Migrating `cy.route()` to `cy.intercept()`](/guides/references/migration-guide#Migrating-cy-route-to-cy-intercept)
 <!-- TODO add examples from the resources below to `cypress-example-recipes` repo -->
 - [Smart GraphQL Stubbing in Cypress](https://glebbahmutov.com/blog/smart-graphql-stubbing/)
   blog post
diff --git a/content/api/commands/origin.md b/content/api/commands/origin.md
old mode 100755
new mode 100644
index 385a54ab13..f91b2594fa
--- a/content/api/commands/origin.md
+++ b/content/api/commands/origin.md
@@ -508,8 +508,6 @@ following Cypress commands will throw errors if used in the callback:
 - `cy.origin()`
 - [`cy.intercept()`](/api/commands/intercept)
 - [`cy.session()`](/api/commands/session)
-- [`cy.server()`](/api/commands/server)
-- [`cy.route()`](/api/commands/route)
 
 ### Other limitations
 
diff --git a/content/api/commands/request.md b/content/api/commands/request.md
index 6f2a9bb0ba..a38a76dd4b 100644
--- a/content/api/commands/request.md
+++ b/content/api/commands/request.md
@@ -357,12 +357,9 @@ browser cookies.
 In other words, `cy.request()` transparently performs all of the underlying
 functions as if it came from the browser.
 
-### [`cy.intercept()`](/api/commands/intercept), [`cy.server()`](/api/commands/server), and [`cy.route()`](/api/commands/route)
+### [`cy.intercept()`](/api/commands/intercept)
 
-#### `cy.request()` sends requests to actual endpoints, bypassing those defined using `cy.route()` or `cy.intercept()`
-
-`cy.server()` and any configuration passed to
-[`cy.server()`](/api/commands/server) has no effect on `cy.request()`.
+#### `cy.request()` sends requests to actual endpoints, bypassing those defined using `cy.intercept()`
 
 The intention of `cy.request()` is to be used for checking endpoints on an
 actual, running server without having to start the front end application.
diff --git a/content/api/commands/route.md b/content/api/commands/route.md
deleted file mode 100644
index 267f9f66fd..0000000000
--- a/content/api/commands/route.md
+++ /dev/null
@@ -1,628 +0,0 @@
----
-title: route
----
-
-Use `cy.route()` to manage the behavior of network requests.
-
-<Alert type="warning">
-
-⚠️ **`cy.server()` and `cy.route()` are deprecated in Cypress 6.0.0**. In a
-future release, support for `cy.server()` and `cy.route()` will be removed.
-Consider using [`cy.intercept()`](/api/commands/intercept) instead. See our
-guide on
-[Migrating `cy.route()` to `cy.intercept()`](/guides/references/migration-guide#Migrating-cy-route-to-cy-intercept)
-
-</Alert>
-
-<Alert type="warning">
-
-⚠️ `cy.route()` and `cy.server()` only support intercepting XMLHttpRequests.
-Requests using the Fetch API and other types of network requests like page loads
-and `<script>` tags will not be intercepted by `cy.route()` and `cy.server()`.
-
-**To support requests using the Fetch API you can use one of the solutions
-below:**
-
-- Use [`cy.intercept()`](/api/commands/intercept) which supports requests using
-  the Fetch API and other types of network requests like page loads. See
-  [`cy.intercept()`](/api/commands/intercept).
-- Polyfill `window.fetch` to spy on and stub requests using `cy.route()` and
-  `cy.server()` by enabling
-  [`experimentalFetchPolyfill`](https://on.cypress.io/experimental). See
-  [#95](https://github.com/cypress-io/cypress/issues/95) for more details and
-  temporary workarounds.
-
-</Alert>
-
-## Syntax
-
-```javascript
-cy.route(url)
-cy.route(url, response)
-cy.route(method, url)
-cy.route(method, url, response)
-cy.route(callbackFn)
-cy.route(options)
-```
-
-### Usage
-
-**<Icon name="check-circle" color="green"></Icon> Correct Usage**
-
-```javascript
-cy.route('/users/**')
-```
-
-### Arguments
-
-**<Icon name="angle-right"></Icon> url** **_(String, Glob, RegExp)_**
-
-Listen for a route matching the specific URL.
-
-**<Icon name="angle-right"></Icon> response** **_(String, Object, Array)_**
-
-Supply a response `body` to _stub_ in the matching route.
-
-**<Icon name="angle-right"></Icon> method** **_(String)_**
-
-Match the route to a specific method (`GET`, `POST`, `PUT`, etc).
-
-<Alert type="bolt">
-
-If no method is defined Cypress will match `GET` requests by default.
-
-</Alert>
-
-**<Icon name="angle-right"></Icon> callbackFn** **_(Function)_**
-
-Listen for a route matching a returned object literal from a callback function.
-Functions that return a `Promise` will automatically be awaited.
-
-**<Icon name="angle-right"></Icon> options** **_(Object)_**
-
-Pass in an options object to change the default behavior of `cy.route()`. By
-default `cy.route()` inherits its options from
-[`cy.server()`](/api/commands/server).
-
-| Option       | Default | Description                                                                       |
-| ------------ | ------- | --------------------------------------------------------------------------------- |
-| `delay`      | `0`     | Delay for stubbed responses (in ms)                                               |
-| `force404`   | `false` | Forcibly send a 404 status when the XHR does not match any existing `cy.route()`. |
-| `headers`    | `null`  | Response headers for stubbed routes                                               |
-| `method`     | `GET`   | Method to match against requests                                                  |
-| `onAbort`    | `null`  | Callback function which fires anytime an XHR is aborted                           |
-| `onRequest`  | `null`  | Callback function when a request is sent                                          |
-| `onResponse` | `null`  | Callback function when a response is returned                                     |
-| `response`   | `null`  | Response body when stubbing routes                                                |
-| `status`     | `200`   | Response status code when stubbing routes                                         |
-| `url`        | `null`  | String or RegExp url to match against request urls                                |
-
-You can also set options for all [`cy.wait()`](/api/commands/wait)'s
-`requestTimeout` and `responseTimeout` globally in the
-[Cypress configuration](/guides/references/configuration) to control how long to
-wait for the request and response of a supplied route.
-
-### Yields [<Icon name="question-circle"/>](/guides/core-concepts/introduction-to-cypress#Subject-Management)
-
-<List><li>`cy.route()` yields `null`.</li><li>`cy.route()` can be aliased, but
-otherwise cannot be chained further.</li></List>
-
-## Examples
-
-### Without Stubbing
-
-If you do not pass a `response` to a route, Cypress will pass the request
-through without stubbing it. We can still wait for the request to resolve later.
-
-#### Wait on XHR `GET` request matching `url`
-
-```javascript
-cy.server()
-cy.route('**/users').as('getUsers')
-cy.visit('/users')
-cy.wait('@getUsers')
-```
-
-#### Wait on XHR's matching `method` and `url`
-
-```javascript
-cy.server()
-cy.route('POST', '**/users').as('postUser')
-cy.visit('/users')
-cy.get('#first-name').type('Julius{enter}')
-cy.wait('@postUser')
-```
-
-#### Setup route to `POST` to login
-
-<Alert type="info">
-
-[Check out our example recipe using `cy.route()` to POST for login in HTML web forms](/examples/examples/recipes#Logging-In)
-
-</Alert>
-
-#### Wait on `url` matching glob
-
-Under the hood Cypress uses [minimatch](https://github.com/isaacs/minimatch) to
-match glob patterns of `url`.
-
-This means you can take advantage of `*` and `**` glob support. This makes it
-_much_ easier to route against dynamic segments without having to build up a
-complex `RegExp`.
-
-We expose [`Cypress.minimatch`](/api/utilities/minimatch) as a function that you
-can use in your console to test routes.
-
-#### Match route against any UserId
-
-```javascript
-cy.server()
-cy.route('**/users/*/comments')
-
-// https://localhost:7777/users/123/comments     <-- matches
-// https://localhost:7777/users/123/comments/465 <-- does not match
-```
-
-#### Use glob to match all segments
-
-```javascript
-cy.server()
-cy.route('**/posts/**')
-
-// https://localhost:7777/posts/1            <-- matches
-// https://localhost:7777/posts/foo/bar/baz  <-- matches
-// https://localhost:7777/posts/quuz?a=b&1=2 <-- matches
-```
-
-#### Override `url` glob matching options
-
-When we check `glob` patterns with
-[minimatch](https://github.com/isaacs/minimatch), by default Cypress uses sets
-`matchBase` to `true`. You can override this option in
-[`cy.server()`](/api/commands/server) options.
-
-If you want to permanently override these options you could do so by setting
-[`Cypress.Server.defaults()`](/api/cypress-api/cypress-server).
-
-```javascript
-cy.server({
-  urlMatchingOptions: { matchBase: false, dot: true }
-})
-cy.route(...)
-```
-
-### With Stubbing
-
-If you pass a `response` to `cy.route()`, Cypress will stub the response in the
-request.
-
-#### `url` as a string
-
-When passing a `string` as the `url`, the XHR's URL must match _exactly_ what
-you've written. You'll want to use the decoded string and not include any hash
-encoding (ie. use `@` instead of `%40`).
-
-```javascript
-cy.server()
-cy.route('https://localhost:7777/surveys/customer?email=john@doe.com', [
-  {
-    id: 1,
-    name: 'john',
-  },
-])
-```
-
-#### `url` as a RegExp
-
-When passing a RegExp as the `url`, the XHR's url will be tested against the
-regular expression and will apply if it passes.
-
-```javascript
-cy.server()
-cy.route(/users\/\d+/, { id: 1, name: 'Phoebe' })
-```
-
-```javascript
-// Application Code
-$.get('https://localhost:7777/users/1337', (data) => {
-  console.log(data) // => {id: 1, name: "Phoebe"}
-})
-```
-
-#### Response functions
-
-You can also use a function as a response which enables you to add logic
-surrounding the response.
-
-Functions that return a `Promise` will automatically be awaited.
-
-```javascript
-const commentsResponse = (routeData) => {
-  //routeData is a reference to the current route's information
-  return {
-    data: someOtherFunction(routeData),
-  }
-}
-
-cy.route('POST', '**/comments', commentsResponse)
-```
-
-#### Matching requests and routes
-
-Any request that matches the `method` and `url` of a route will be responded to
-based on the configuration of that route.
-
-<Alert type="bolt">
-
-`GET` is the default HTTP method used to match routes. If you want to stub a
-route with another HTTP method such as `POST` then you
-[must be explicit about the method](#Arguments).
-
-</Alert>
-
-<Alert type="info">
-
-If a request doesn't match any route then the behavior depends on the value of
-the `force404` option on the [`cy.server()`](/api/commands/server):
-
-- if `force404` is `false` (the default) then the request will
-  [pass through to the server](/guides/guides/network-requests#Use-Server-Responses).
-- if `force404` is `true` then the response [will be a 404](#Notes).
-
-You can [read more about this behavior here.](/api/commands/server#Options)
-
-</Alert>
-
-#### Specify the method
-
-The below example matches all `DELETE` requests to "/users" and stubs a response
-with an empty JSON object.
-
-```javascript
-cy.server()
-cy.route('DELETE', '**/users/*', {})
-```
-
-#### Making multiple requests to the same route
-
-You can test a route multiple times with unique response objects by using
-[aliases](/guides/core-concepts/variables-and-aliases#Aliases) and
-[cy.wait()](/api/commands/wait). Each time we use `cy.wait()` for an alias,
-Cypress waits for the next nth matching request.
-
-```js
-cy.server()
-cy.route('/beetles', []).as('getBeetles')
-cy.get('#search').type('Weevil')
-
-// wait for the first response to finish
-cy.wait('@getBeetles')
-
-// the results should be empty because we
-// responded with an empty array first
-cy.get('#beetle-results').should('be.empty')
-
-// now re-define the /beetles response
-cy.route('/beetles', [{ name: 'Geotrupidae' }])
-
-cy.get('#search').type('Geotrupidae')
-
-// now when we wait for 'getBeetles' again, Cypress will
-// automatically know to wait for the 2nd response
-cy.wait('@getBeetles')
-
-// we responded with 1 beetle item so now we should
-// have one result
-cy.get('#beetle-results').should('have.length', 1)
-```
-
-### Fixtures
-
-Instead of writing a response inline you can automatically connect a response
-with a [`cy.fixture()`](/api/commands/fixture).
-
-```javascript
-cy.server()
-cy.route('**/posts/*', 'fixture:logo.png').as('getLogo')
-cy.route('**/users', 'fixture:users/all.json').as('getUsers')
-cy.route('**/admin', 'fx:users/admin.json').as('getAdmin')
-```
-
-You may want to define the `cy.route()` after receiving the fixture and working
-with its data.
-
-```javascript
-cy.fixture('user').then((user) => {
-  user.firstName = 'Jane'
-  // work with the users array here
-
-  cy.route('GET', '**/user/123', user)
-})
-
-cy.visit('/users')
-cy.get('.user').should('include', 'Jane')
-```
-
-You can also reference fixtures as strings directly in the response by passing
-an aliased fixture with `@`.
-
-```javascript
-cy.fixture('user').as('fxUser')
-cy.route('POST', '**/users', '@fxUser')
-```
-
-### Options
-
-#### Pass in an options object
-
-```javascript
-cy.server()
-cy.route({
-  method: 'DELETE',
-  url: '**/user/*',
-  status: 412,
-  response: {
-    rolesCount: 2,
-  },
-  delay: 500,
-  headers: {
-    'X-Token': null,
-  },
-  onRequest: (xhr) => {
-    // do something with the
-    // raw XHR object when the
-    // request initially goes out
-  },
-  onResponse: (xhr) => {
-    // do something with the
-    // raw XHR object when the
-    // response comes back
-  },
-})
-```
-
-#### Simulate a server redirect
-
-Below we simulate the server returning `503` with a stubbed empty JSON response
-body.
-
-```javascript
-cy.route({
-  method: 'POST',
-  url: '**/login',
-  response: {
-    // simulate a redirect to another page
-    redirect: '/error',
-  },
-})
-```
-
-#### Setup route to error on `POST` to login
-
-<Alert type="info">
-
-[Check out our 'XHR Web Forms' example recipe using `cy.route()` to simulate a `503` on `POST` to login](/examples/examples/recipes#Logging-In)
-
-</Alert>
-
-#### Change `headers`
-
-By default, Cypress will automatically set `Content-Type` and `Content-Length`
-based on what your `response body` looks like.
-
-If you'd like to override this, explicitly pass in `headers` as an object
-literal.
-
-```javascript
-cy.route({
-  url: '**/user-image.png',
-  response: 'fx:logo.png,binary', // binary encoding
-  headers: {
-    // set content-type headers
-    'content-type': 'binary/octet-stream',
-  },
-})
-```
-
-#### Use delays for responses
-
-You can pass in a `delay` option that causes a delay (in ms) to the `response`
-for matched requests. The example below will cause the response to be delayed by
-3 secs. This can be useful for testing loading states, like loading spinners, in
-the DOM before the request responds.
-
-```javascript
-cy.route({
-  method: 'PATCH',
-  url: '**/activities/*',
-  response: {},
-  delay: 3000,
-})
-```
-
-### Function
-
-#### Set the routing options using a callback function
-
-```javascript
-cy.route(() => {
-  // ...do some custom logic here..
-
-  // and return an appropriate routing object here
-  return {
-    method: 'POST',
-    url: '**/users/*/comments',
-    response: this.commentsFixture,
-  }
-})
-```
-
-#### Functions that return promises are awaited
-
-```javascript
-cy.route(() => {
-  // a silly example of async return
-  return new Cypress.Promise((resolve) => {
-    // resolve this promise after 1 second
-    setTimeout(() => {
-      resolve({
-        method: 'PUT',
-        url: '**/posts/**',
-        response: '@postFixture',
-      })
-    }, 1000)
-  })
-})
-```
-
-## Notes
-
-### Debugging
-
-#### Understanding stubbed vs regular XHRs
-
-Cypress indicates whether an XHR sent back a stubbed response or actually went
-out to a server in its Command Log
-
-XHRs that display `(XHR STUB)` in the Command Log have been stubbed and their
-response, status, headers, and delay have been controlled by your matching
-`cy.route()`.
-
-XHRs that display `(XHR)` in the Command Log have _not_ been stubbed and were
-passed directly through to a server.
-
-<DocsImage src="/img/api/route/xhr-stub-versus-not-stubbed-routes-in-command-log.png" alt="XHR Command Log when not stubbed" ></DocsImage>
-
-Cypress also logs whether the XHR was stubbed or not to the console when you
-click on the command in the Command Log. It will indicate whether a request was
-stubbed, which url it matched or that it did not match any routes.
-
-<DocsImage src="/img/api/route/console-log-shows-if-route-was-stubbed-also.png" alt="XHR Command Log stubbed" ></DocsImage>
-
-Even the `Initiator` is included, which is a stack trace to what caused the XHR
-to be sent.
-
-### `cy.route()` cannot be debugged using [`cy.request()`](/api/commands/request)
-
-#### `cy.request()` sends requests to actual endpoints, bypassing those defined using `cy.route()`
-
-The intention of `cy.request()` is to be used for checking endpoints on an
-actual, running server without having to start the front end application.
-
-### Matches
-
-#### Matching origins and non origin URL's
-
-When Cypress matches up an outgoing XHR request to a `cy.route()`, it actually
-attempts to match it against both the fully qualified URL and then additionally
-without the URL's origin.
-
-```javascript
-cy.route('**/users/*')
-```
-
-The following XHRs which were `xhr.open(...)` with these URLs would:
-
-**Match:**
-
-- `/users/1`
-- `http://localhost:2020/users/2`
-- `https://google.com/users/3`
-
-**Not Match:**
-
-- `/users/4/foo`
-- `http://localhost:2020/users/5/foo`
-
-### No matches
-
-#### Requests that don't match any routes
-
-You can force requests that do _not_ match a route to return a `404` status and
-an empty body by passing an option to the `cy.server()` like so:
-
-```javascript
-cy.server({ force404: true })
-```
-
-You can [read more about this here.](/api/commands/server#Options)
-
-## Rules
-
-### Requirements [<Icon name="question-circle"/>](/guides/core-concepts/introduction-to-cypress#Chains-of-Commands)
-
-<List><li>`cy.route()` requires being chained off of `cy`.</li></List>
-
-### Assertions [<Icon name="question-circle"/>](/guides/core-concepts/introduction-to-cypress#Assertions)
-
-<List><li>`cy.route()` cannot have any assertions chained.</li></List>
-
-### Timeouts [<Icon name="question-circle"/>](/guides/core-concepts/introduction-to-cypress#Timeouts)
-
-<List><li>`cy.route()` cannot time out.</li></List>
-
-## Command Log
-
-```javascript
-cy.server()
-cy.route(/accounts/).as('accountsGet')
-cy.route(/company/, 'fixtures:company').as('companyGet')
-cy.route(/teams/, 'fixtures:teams').as('teamsGet')
-```
-
-Whenever you start a server and add routes, Cypress will display a new
-Instrument Panel called _Routes_. It will list the routing table in the
-Instrument Panel, including the `method`, matched URL pattern, `stubbed`,
-`alias` and number of matched requests:
-
-<!-- Code to reproduce screenshot:
-it('cy.route command log', () => {
-    cy.server()
-    cy.route(/accounts/).as('accountsGet')
-    cy.route(/company/, 'fixtures:company').as('companyGet')
-    cy.route(/teams/, 'fixtures:teams').as('teamsGet')
-    cy.window().then(({ XMLHttpRequest }) => {
-        const xhr = new XMLHttpRequest()
-        xhr.open('GET', '/accounts?page=1')
-        xhr.send()
-
-        const xhr2 = new XMLHttpRequest()
-        xhr2.open('GET', '/company')
-        xhr2.send()
-
-        const xhr3 = new XMLHttpRequest()
-        xhr3.open('GET', '/teams?page=1')
-        xhr3.send()
-    })
-})
--->
-
-<DocsImage src="/img/api/route/routing-table-displayed-in-command-log-for-cy-route.png" alt="Command Log routing table" ></DocsImage>
-
-When XHRs are made, Cypress will log them in the Command Log and indicate
-whether they matched a routing alias:
-
-<DocsImage src="/img/api/route/some-xhr-responses-including-200-and-500-status-codes.png" alt="Command Log XHR alias route" ></DocsImage>
-
-The circular indicator is filled if the request went to the destination server,
-but unfilled if the request was stubbed with a response.
-
-<DocsImage src="/img/api/route/console-log-shows-status-duration-response-request-and-other-data-for-routing.png" alt="Console Log XHR alias route" ></DocsImage>
-
-[Read more about request logging in Cypress.](/guides/guides/network-requests#Command-Log)
-
-## History
-
-| Version                                     | Changes                         |
-| ------------------------------------------- | ------------------------------- |
-| [6.0.0](/guides/references/changelog#6-0-0) | Deprecated `cy.route()` command |
-
-## See also
-
-- [Migrating `cy.route()` to `cy.intercept()`](/guides/references/migration-guide#Migrating-cy-route-to-cy-intercept)
-- [`.as()`](/api/commands/as)
-- [`cy.fixture()`](/api/commands/fixture)
-- [`cy.server()`](/api/commands/server)
-- [`cy.wait()`](/api/commands/wait)
-- [Guide: Network Requests](/guides/guides/network-requests)
-- [Recipe: Logging in - XHR Web Forms](/examples/examples/recipes#Logging-In)
diff --git a/content/api/commands/server.md b/content/api/commands/server.md
deleted file mode 100644
index b895d2a923..0000000000
--- a/content/api/commands/server.md
+++ /dev/null
@@ -1,352 +0,0 @@
----
-title: server
----
-
-Start a server to begin routing responses to [cy.route()](/api/commands/route)
-and to change the behavior of network requests.
-
-<Alert type="warning">
-
-⚠️ **`cy.server()` and `cy.route()` are deprecated in Cypress 6.0.0**. In a
-future release, support for `cy.server()` and `cy.route()` will be removed.
-Consider using [`cy.intercept()`](/api/commands/intercept) instead. See our
-guide on
-[Migrating `cy.route()` to `cy.intercept()`](/guides/references/migration-guide#Migrating-cy-route-to-cy-intercept)
-
-</Alert>
-
-<Alert type="warning">
-
-⚠️ `cy.route()` and `cy.server()` only support intercepting XMLHttpRequests.
-Requests using the Fetch API and other types of network requests like page loads
-and `<script>` tags will not be intercepted by `cy.route()` and `cy.server()`.
-
-**To support requests using the Fetch API you can use one of the solutions
-below:**
-
-- Use [`cy.intercept()`](/api/commands/intercept) which supports requests using
-  the Fetch API and other types of network requests like page loads. See
-  [`cy.intercept()`](/api/commands/intercept).
-- Polyfill `window.fetch` to spy on and stub requests using `cy.route()` and
-  `cy.server()` by enabling
-  [`experimentalFetchPolyfill`](https://on.cypress.io/experimental). See
-  [#95](https://github.com/cypress-io/cypress/issues/95) for more details and
-  temporary workarounds.
-
-</Alert>
-
-## Syntax
-
-```javascript
-cy.server()
-cy.server(options)
-```
-
-### Usage
-
-**<Icon name="check-circle" color="green"></Icon> Correct Usage**
-
-```javascript
-cy.server()
-```
-
-### Arguments
-
-**<Icon name="angle-right"></Icon> options** **_(Object)_**
-
-Pass in an options object to change the default behavior of `cy.server()`. These
-options are used for 2 different purposes:
-
-- As defaults that are merged into [`cy.route()`](/api/commands/route).
-- As configuration behavior for _all_ requests.
-
-#### The following options are merged in as default options to [`cy.route()`](/api/commands/route)
-
-| Option       | Default     | Description                                             |
-| ------------ | ----------- | ------------------------------------------------------- |
-| `delay`      | `0`         | delay for stubbed responses (in ms)                     |
-| `headers`    | `null`      | response headers for stubbed routes                     |
-| `method`     | `"GET"`     | method to match against requests                        |
-| `onAbort`    | `undefined` | callback function which fires anytime an XHR is aborted |
-| `onRequest`  | `undefined` | callback function when a request is sent                |
-| `onResponse` | `undefined` | callback function when a response is returned           |
-| `response`   | `null`      | response body when stubbing routes                      |
-| `status`     | `200`       | response status code when stubbing routes               |
-
-#### The following options control the behavior of the server affecting all requests
-
-| Option               | Default               | Description                                                                                                                                                                          |
-| -------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `enable`             | `true`                | pass `false` to disable existing route stubs                                                                                                                                         |
-| `force404`           | `false`               | forcibly send XHR's a 404 status when the XHR's do not match any existing route                                                                                                      |
-| `onAnyAbort`         | `undefined`           | callback function called when any XHR is aborted                                                                                                                                     |
-| `onAnyRequest`       | `undefined`           | callback function called when any request is sent                                                                                                                                    |
-| `onAnyResponse`      | `undefined`           | callback function called when any response is returned                                                                                                                               |
-| `urlMatchingOptions` | `{ matchBase: true }` | The default options passed to `minimatch` when using glob strings to match URLs                                                                                                      |
-| `ignore`             | function              | Callback function that filters requests from ever being logged or stubbed. By default this matches against asset-like requests such as for `.js`, `.jsx`, `.html`, and `.css` files. |
-
-### Yields [<Icon name="question-circle"/>](/guides/core-concepts/introduction-to-cypress#Subject-Management)
-
-<List><li>`cy.server()` yields `null`.</li><li>`cy.server()` cannot be chained
-further.</li></List>
-
-## Examples
-
-### No Args
-
-#### After starting a server:
-
-- Any request that does **NOT** match a [`cy.route()`](/api/commands/route) will
-  [pass through to the server](/guides/guides/network-requests#Use-Server-Responses).
-- Any request that matches the `options.ignore` function will **NOT** be logged
-  or stubbed.
-- You will see requests named as `(XHR Stub)` or `(XHR)` in the Command Log.
-
-```javascript
-cy.server()
-```
-
-### Options
-
-#### Change defaults for [`cy.route()`](/api/commands/route)
-
-By default [`cy.route()`](/api/commands/route) inherits some of its options from
-`cy.server()`.
-
-In this example, our matching requests will be delayed 1000ms and have a status
-of `422`, but its `response` will be what was set in
-[`cy.route()`](/api/commands/route).
-
-```javascript
-cy.server({
-  method: 'POST',
-  delay: 1000,
-  status: 422,
-  response: {},
-})
-
-cy.route('/users/', { errors: 'Name cannot be blank' })
-```
-
-#### Change the default delay for all routes
-
-Adding delay can help simulate real world network latency. Normally stubbed
-responses return in under 20ms. Adding a delay can help you visualize how your
-application's state reacts to requests that are in flight.
-
-```javascript
-// delay each route's response 1500ms
-cy.server({ delay: 1500 })
-```
-
-#### Send 404s on unmatched requests
-
-If you'd like Cypress to automatically send requests that do _NOT_ match routes
-the following response:
-
-| Status | Body | Headers |
-| ------ | ---- | ------- |
-| `404`  | ""   | `null`  |
-
-Set `force404` to `true`.
-
-```javascript
-cy.server({ force404: true })
-cy.route('/activities/**', 'fixture:activities.json')
-```
-
-```javascript
-// Application Code
-$(() => {
-  $.get('/activities')
-
-  // this will be sent back 404 since it
-  // does not match any of the cy.routes
-  $.getJSON('/users.json')
-})
-```
-
-#### Change the default response headers for all routes
-
-When you stub requests, you can automatically control their response `headers`.
-This is useful when you want to send back meta data in the `headers`, such as
-_pagination_ or _token_ information.
-
-<Alert type="info">
-
-Cypress automatically sets `Content-Length` and `Content-Type` based on the
-response `body` you stub.
-
-</Alert>
-
-```javascript
-cy.server({
-  headers: {
-    'x-token': 'abc-123-foo-bar',
-  },
-})
-
-cy.route('GET', '/users/1', { id: 1, name: 'Amanda' }).as('getUser')
-cy.visit('/users/1/profile')
-cy.wait('@getUser')
-  .its('responseHeaders')
-  .should('have.property', 'x-token', 'abc-123-foo-bar') // true
-```
-
-```javascript
-// Application Code
-
-// lets use the native XHR object
-const xhr = new XMLHttpRequest()
-
-xhr.open('GET', '/users/1')
-
-xhr.onload = function () {
-  const token = this.getResponseHeader('x-token')
-
-  console.log(token) // => abc-123-foo-bar
-}
-
-xhr.send()
-```
-
-#### Set a custom request header for all requests
-
-```js
-cy.server({
-  onAnyRequest: (route, proxy) => {
-    proxy.xhr.setRequestHeader('CUSTOM-HEADER', 'Header value')
-  },
-})
-```
-
-#### Change the default filtering
-
-`cy.server()` comes with an `ignore` function that by default filters out any
-requests that are for static assets like `.html`, `.js`, `.jsx`, and `.css`.
-
-Any request that passes the `ignore` will be ignored - it will not be logged nor
-will it be stubbed in any way (even if it matches a specific
-[`cy.route()`](/api/commands/route)).
-
-The idea is that we never want to interfere with static assets that are fetched
-via Ajax.
-
-**The default filter function in Cypress is:**
-
-```javascript
-const ignore = (xhr) => {
-  // this function receives the xhr object in question and
-  // will ignore if it's a GET that appears to be a static resource
-  return (
-    xhr.method === 'GET' &&
-    /\.(jsx?|coffee|html|less|s?css|svg)(\?.*)?$/.test(xhr.url)
-  )
-}
-```
-
-**You can override this function with your own specific logic:**
-
-```javascript
-cy.server({
-  ignore: (xhr) => {
-    // specify your own function that should return
-    // truthy if you want this xhr to be ignored,
-    // not logged, and not stubbed.
-  },
-})
-```
-
-If you would like to change the default option for **ALL** `cy.server()` you
-[can change this option permanently](/api/cypress-api/cypress-server#Options).
-
-#### Turn off the server after you've started it
-
-You can disable all stubbing and its effects and restore it to the default
-behavior as a test is running. By setting `enable` to `false`, this disables
-stubbing routes and XHR's will no longer show up as (XHR Stub) in the Command
-Log. However, routing aliases can continue to be used and will continue to match
-requests, but will not affect responses.
-
-```javascript
-cy.server()
-cy.route('POST', '/users', {}).as('createUser')
-cy.server({ enable: false })
-```
-
-## Notes
-
-### State between tests
-
-#### Server persists until the next test runs
-
-Cypress automatically continues to persist the server and routing configuration
-even after a test ends. This means you can continue to use your application and
-still benefit from stubbing or other server configuration.
-
-However between tests, when a new test runs, the previous configuration is
-restored to a clean state. No configuration leaks between tests.
-
-#### Outstanding requests are automatically aborted between tests
-
-When a new test runs, any outstanding requests still in flight are automatically
-aborted. In fact this happens by default whether or not you've even started a
-`cy.server()`.
-
-### `cy.visit()`
-
-#### Server can be started before you [`cy.visit()`](/api/commands/visit)
-
-Oftentimes your application may make initial requests immediately when it loads
-(such as authenticating a user). Cypress makes it possible to start your server
-and define routes before a [cy.visit()](/api/commands/visit). Upon the next
-visit, the server + routes will be instantly applied before your application
-loads.
-
-You can [read more about XHR strategy here](/guides/guides/network-requests).
-
-### `cy.request()`
-
-#### `cy.server()` does not effect [cy.request()](/api/commands/request)
-
-`cy.server()` and any configuration passed to `cy.server()` has no effect on
-[cy.request()](/api/commands/request).
-
-The intention of [cy.request()](/api/commands/request) is to be used for
-checking endpoints on an actual, running server without having to start the
-front end application.
-
-## Rules
-
-### Requirements [<Icon name="question-circle"/>](/guides/core-concepts/introduction-to-cypress#Chains-of-Commands)
-
-<List><li>`cy.server()` requires being chained off of `cy`.</li></List>
-
-### Assertions [<Icon name="question-circle"/>](/guides/core-concepts/introduction-to-cypress#Assertions)
-
-<List><li>`cy.server()` cannot have any assertions chained.</li></List>
-
-### Timeouts [<Icon name="question-circle"/>](/guides/core-concepts/introduction-to-cypress#Timeouts)
-
-<List><li>`cy.server()` cannot time out.</li></List>
-
-## Command Log
-
-- `cy.server()` does _not_ log in the Command Log
-
-## History
-
-| Version                                       | Changes                                |
-| --------------------------------------------- | -------------------------------------- |
-| [6.0.0](/guides/references/changelog#6-0-0)   | Deprecated `cy.server()` command       |
-| [5.0.0](/guides/references/changelog#5-0-0)   | Renamed `whitelist` option to `ignore` |
-| [0.13.6](/guides/references/changelog#0-13-6) | Added `onAbort` callback option        |
-| [0.5.10](/guides/references/changelog#0-5-10) | Added `delay` option                   |
-| [0.3.3](/guides/references/changelog#0-3-3)   | Added `whitelist` option               |
-| [< 0.3.3](/guides/references/changelog#0-3-3) | `cy.server()` command added            |
-
-## See also
-
-- [Network Requests](/guides/guides/network-requests)
-- [`cy.route()`](/api/commands/route)
-- [`cy.wait()`](/api/commands/wait)
diff --git a/content/api/commands/wait.md b/content/api/commands/wait.md
index 4095d33e49..9e60fafd16 100644
--- a/content/api/commands/wait.md
+++ b/content/api/commands/wait.md
@@ -351,6 +351,4 @@ following:
 
 - [`.as()`](/api/commands/as)
 - [`cy.intercept()`](/api/commands/intercept)
-- [`cy.route()`](/api/commands/route)
-- [`cy.server()`](/api/commands/server)
 - [`.spread()`](/api/commands/spread)
diff --git a/content/api/cypress-api/cypress-server.md b/content/api/cypress-api/cypress-server.md
deleted file mode 100644
index ff2748683b..0000000000
--- a/content/api/cypress-api/cypress-server.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: Cypress.Server
----
-
-<Alert type="warning">
-
-⚠️ **`cy.server()` and `cy.route()` are deprecated in Cypress 6.0.0**. In a
-future release, support for `cy.server()` and `cy.route()` will be removed.
-Consider using [`cy.intercept()`](/api/commands/intercept) instead. See our
-guide on
-[Migrating `cy.route()` to `cy.intercept()`](/guides/references/migration-guide#Migrating-cy-route-to-cy-intercept)
-
-</Alert>
-
-Permanently change the default options for all
-[`cy.server()`](/api/commands/server) instances
-
-## Syntax
-
-```javascript
-Cypress.Server.defaults(options)
-```
-
-### Arguments
-
-**<Icon name="angle-right"></Icon> options** **_(Object)_**
-
-Pass in an options object to change the default behavior of `Cypress.Server`.
-
-## Examples
-
-### Options
-
-**These options will be the new defaults.**
-
-```javascript
-// pass anything here you'd normally pass to cy.server().
-Cypress.Server.defaults({
-  delay: 500,
-  force404: false,
-  ignore: (xhr) => {
-    // handle custom logic for filtering XHR requests
-  },
-})
-```
-
-## Notes
-
-**Where to put server configuration**
-
-::include{file=partials/support-file-configuration.md}
-
-## See also
-
-- [`cy.server()`](/api/commands/server)
diff --git a/content/faq/questions/using-cypress-faq.md b/content/faq/questions/using-cypress-faq.md
index a69fc15053..8ff6d4e0dd 100644
--- a/content/faq/questions/using-cypress-faq.md
+++ b/content/faq/questions/using-cypress-faq.md
@@ -919,8 +919,6 @@ application under test runs in any way, so you can safely ignore this warning.
 The network traffic between Cypress and the backend server still happens via
 HTTPS.
 
-See also the [Web Security](/guides/guides/web-security) guide.
-
 ## <Icon name="angle-right"></Icon> Is there an option to run Cypress in CI with Developer Tools open? We want to track network and console issues.
 
 No. There is not currently a way to run Cypress in `cypress run` with Developer
diff --git a/content/guides/guides/cross-browser-testing.md b/content/guides/guides/cross-browser-testing.md
index 6cbbe3fa22..47f666822c 100644
--- a/content/guides/guides/cross-browser-testing.md
+++ b/content/guides/guides/cross-browser-testing.md
@@ -14,7 +14,7 @@ browser engine), and Firefox.
 <strong class="alert-header">Web Security</strong>
 
 Tests that require the
-[`chromeWebSecurity` configuration option to be disabled](/guides/guides/web-security#Disabling-Web-Security)
+[`chromeWebSecurity` configuration option to be disabled](/guides/references/configuration#Browser)
 may experience issues in non-Chromium based browsers.
 
 </Alert>
diff --git a/content/guides/guides/network-requests.md b/content/guides/guides/network-requests.md
index 825ea2162f..d44276245f 100644
--- a/content/guides/guides/network-requests.md
+++ b/content/guides/guides/network-requests.md
@@ -541,7 +541,7 @@ test in the Command Log. Here is an example of what this looks like:
 The circular indicator on the left side indicates if the request went to the
 destination server or not. If the circle is solid, the request went to the
 destination server; if it is outlined, the response was stubbed by
-`cy.intercept()` or `cy.route()` and not sent outbound.
+`cy.intercept()` and not sent outbound.
 
 If we re-run our previous test to make the same requests, but this time, add a
 `cy.intercept()` to stub the response to `/users`, we can see that the indicator
@@ -615,9 +615,6 @@ following:
 - [See how to make a request with `cy.request()`](/api/commands/request)
 - [Real World App (RWA)](https://github.com/cypress-io/cypress-realworld-app)
   test suites to see Cypress network handling in action.
-- Read
-  [Difference between cy.route and cy.route2](https://glebbahmutov.com/blog/cy-route-vs-route2/)
-  blog post
 - Read the blog post
   [Asserting Network Calls from Cypress Tests](https://www.cypress.io/blog/2019/12/23/asserting-network-calls-from-cypress-tests/)
 - If you want to test the application in offline mode, read
diff --git a/content/guides/guides/stubs-spies-and-clocks.md b/content/guides/guides/stubs-spies-and-clocks.md
index 7a05772216..13e202f1c7 100644
--- a/content/guides/guides/stubs-spies-and-clocks.md
+++ b/content/guides/guides/stubs-spies-and-clocks.md
@@ -161,8 +161,7 @@ You can call [`cy.clock()`](/api/commands/clock) **prior** to visiting your
 application and we will automatically bind it to the application on the next
 [`cy.visit()`](/api/commands/visit). The same concept applies to mounting a
 component with [`cy.mount()`](/api/commands/mount). We bind **before** any
-timers from your code can be invoked. This works identically to
-[`cy.server()`](/api/commands/server) and [`cy.route()`](/api/commands/route).
+timers from your code can be invoked.
 
 ##### Restore the clock
 
diff --git a/content/guides/guides/web-security.md b/content/guides/guides/web-security.md
deleted file mode 100644
index 49df21fbc8..0000000000
--- a/content/guides/guides/web-security.md
+++ /dev/null
@@ -1,417 +0,0 @@
----
-title: Web Security
-e2eSpecific: true
----
-
-Browsers adhere to a strict
-[same-origin policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy).
-This means that browsers restrict access between `<iframes>` when their origin
-policies do not match.
-
-Because Cypress works from within the browser, Cypress must be able to directly
-communicate with your remote application at all times. Unfortunately, browsers
-naturally try to prevent Cypress from doing this.
-
-To get around these restrictions, Cypress implements some strategies involving
-JavaScript code, the browser's internal APIs, and network proxying to _play by
-the rules_ of same-origin policy. It is our goal to fully automate the
-application under test without you needing to modify your application's code -
-and we are _mostly_ able to do this.
-
-#### Examples of what Cypress does under the hood:
-
-- Injects
-  [`document.domain`](https://developer.mozilla.org/en-US/docs/Web/API/Document/domain)
-  into `text/html` pages.
-- Proxies all HTTP / HTTPS traffic.
-- Changes the hosted URL to match that of the application under test.
-- Uses the browser's internal APIs for network level traffic.
-
-When Cypress first loads, the internal Cypress web application is hosted on a
-random port: something like `http://localhost:65874/__/`.
-
-After the first [`cy.visit()`](/api/commands/visit) command is issued in a test,
-Cypress changes its URL to match the origin of your remote application, thereby
-solving the first major hurdle of same-origin policy. Your application's code
-executes the same as it does outside of Cypress, and everything works as
-expected.
-
-<Alert type="info">
-
-<strong class="alert-header">How is HTTPS supported?</strong>
-
-Cypress does some pretty interesting things under the hood to make testing HTTPS
-sites work. Cypress enables you to control and stub at the network level.
-Therefore, Cypress must assign and manage browser certificates to be able to
-modify the traffic in real time.
-
-You'll notice Chrome display a warning that the 'SSL certificate does not
-match'. This is normal and correct. Under the hood we act as our own CA
-authority and issue certificates dynamically in order to intercept requests
-otherwise impossible to access. We only do this for the superdomain currently
-under test, and bypass other traffic. That's why if you open a tab in Cypress to
-another host, the certificates match as expected.
-
-Note, that Cypress allows you to optionally specify CA / client certificate
-information for use with HTTPS sites. See
-[Configuring client certificates](/guides/references/client-certificates). If
-the remote server requests a client certificate for a configured URL, Cypress
-will supply it.
-
-</Alert>
-
-## Limitations
-
-It's important to note that although we do our **very best** to ensure your
-application works normally inside of Cypress, there _are_ some limitations you
-need to be aware of.
-
-### Same superdomain per test
-
-::include{file=partials/single-domain-workaround.md}
-
-Because Cypress changes its own host URL to match that of your applications, it
-requires that the URLs navigated to have the same superdomain for the entirety
-of a single test.
-
-If you attempt to visit two different superdomains, Cypress will error. Visiting
-subdomains works fine. You can visit different superdomains in _different_
-tests, but not in the _same_ test.
-
-```javascript
-it('navigates', () => {
-  cy.visit('https://www.cypress.io')
-  cy.visit('https://docs.cypress.io') // yup all good
-})
-```
-
-```javascript
-it('navigates', () => {
-  cy.visit('https://apple.com')
-  cy.visit('https://google.com') // this will error
-})
-```
-
-```javascript
-it('navigates', () => {
-  cy.visit('https://apple.com')
-})
-
-// split visiting different origin in another test
-it('navigates to new origin', () => {
-  cy.visit('https://google.com') // yup all good
-})
-```
-
-Although Cypress tries to enforce this limitation, it is possible for your
-application to bypass Cypress's ability to detect this.
-
-#### Examples of test cases that will error due to superdomain limitations
-
-1. [`.click()`](/api/commands/click) an `<a>` with an `href` to a different
-   superdomain.
-2. [`.submit()`](/api/commands/submit) a `<form>` that causes your web server to
-   redirect to you a different superdomain.
-3. Issue a JavaScript redirect in your application, such as
-   `window.location.href = '...'`, to a different superdomain.
-
-In each of these situations, Cypress will lose the ability to automate your
-application and will immediately error.
-
-Read on to learn about
-[working around these common problems](/guides/guides/web-security#Common-Workarounds)
-or even
-[disabling web security](/guides/guides/web-security#Disabling-Web-Security)
-altogether.
-
-### Cross-origin iframes
-
-If your site embeds an `<iframe>` that is a cross-origin frame, Cypress will not
-be able to automate or communicate with this `<iframe>`.
-
-#### Examples of uses for cross-origin iframes
-
-- Embedding a Vimeo or YouTube video.
-- Displaying a credit card form from Stripe or Braintree.
-- Displaying an embedded login form from Auth0.
-- Showing comments from Disqus.
-
-It's actually _possible_ for Cypress to accommodate these situations the same
-way Selenium does, but you will never have _native_ access to these iframes from
-inside of Cypress.
-
-As a workaround, you may be able to use
-[`window.postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage)
-to directly communicate with these iframes and control them (if the 3rd party
-iframe supports it).
-
-Other than that, you'll have to wait for us to implement APIs to support this
-(check our [open issue](https://github.com/cypress-io/cypress/issues/136)), or
-you can
-[disable web security](/guides/guides/web-security#Disabling-Web-Security).
-
-### Insecure Content
-
-Because of the way Cypress is designed, if you are testing an HTTPS site,
-Cypress will error anytime you attempt to navigate back to an HTTP site. This
-behavior helps highlight a _pretty serious security problem_ with your
-application.
-
-#### Example of accessing insecure content
-
-```javascript
-// Test code
-cy.visit('https://app.corp.com')
-```
-
-In your application code, you set `cookies` and store a session on the browser.
-Now let's imagine you have a single `insecure` link (or JavaScript redirect) in
-your application code.
-
-```html
-<!-- Application code -->
-<html>
-  <a href="http://app.corp.com/page2">Page 2</a>
-</html>
-```
-
-Cypress will immediately fail with the following test code:
-
-```javascript
-// Test code
-cy.visit('https://app.corp.com')
-cy.get('a').click() // will fail
-```
-
-Browsers refuse to display insecure content on a secure page. Because Cypress
-initially changed its URL to match `https://app.corp.com` when the browser
-followed the `href` to `http://app.corp.com/page2`, the browser will refuse to
-display the contents.
-
-Now you may be thinking, _This sounds like a problem with Cypress because when I
-work with my application outside of Cypress it works just fine._
-
-However, the truth is, Cypress is exposing a _security vulnerability_ in your
-application, and you _want_ it to fail in Cypress.
-
-`cookies` that do not have their `secure` flag set to `true` will be sent as
-clear text to the insecure URL. This leaves your application vulnerable to
-session hijacking.
-
-This security vulnerability exists **even if** your web server forces a
-`301 redirect` back to the HTTPS site. The original HTTP request was still made
-once, exposing insecure session information.
-
-#### The solution
-
-Update your HTML or JavaScript code to not navigate to an insecure HTTP page and
-instead only use HTTPS. Additionally make sure that cookies have their `secure`
-flag set to `true`.
-
-If you're in a situation where you don't control the code, or otherwise cannot
-work around this, you can bypass this restriction in Cypress by
-[disabling web security](/guides/guides/web-security#Disabling-Web-Security).
-
-### Same port per test
-
-Cypress requires that the URLs navigated to have the same port (if specified)
-for the entirety of a single test. This matches the behavior of the browser's
-normal
-[same-origin policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy).
-
-## Common Workarounds
-
-Let's investigate how you might encounter cross-origin errors in your test code
-and break down how to work around them in Cypress.
-
-### External Navigation
-
-The most common situation where you might encounter this error is when you click
-on an `<a>` that navigates to another superdomain.
-
-```html
-<!-- Application code that is served at `localhost:8080` -->
-<html>
-  <a href="https://google.com">Google</a>
-</html>
-```
-
-```javascript
-// Test code
-cy.visit('http://localhost:8080') // where your web server + HTML is hosted
-cy.get('a').click() // browser attempts to load google.com, Cypress errors
-```
-
-We do not recommend visiting a superdomain that you don't control in your tests
-which you can read more about
-[here](/guides/references/best-practices#Visiting-external-sites)
-
-Instead, all you can test is that the `href` property is correct!
-
-```javascript
-// this test verifies the behavior and will run considerably faster
-cy.visit('http://localhost:8080')
-cy.get('a').should('have.attr', 'href', 'https://google.com') // no page load!
-```
-
-Okay but let's say you're worried about `google.com` serving up the right HTML
-content. How would you test that? We can make a
-[`cy.request()`](/api/commands/request) directly to it.
-[`cy.request()`](/api/commands/request) is _NOT bound to CORS or same-origin
-policy_.
-
-```javascript
-cy.visit('http://localhost:8080')
-cy.get('a').then(($a) => {
-  // pull off the fully qualified href from the <a>
-  const url = $a.prop('href')
-
-  // make a cy.request to it
-  cy.request(url).its('body').should('include', '</html>')
-})
-```
-
-If you still require visiting a different origin URL then read about
-[disabling web security](/guides/guides/web-security#Disabling-Web-Security).
-
-### Form Submission Redirects
-
-When you submit a regular HTML form, the browser will follow the HTTP(s)
-request.
-
-```html
-<!-- Application code that is served at `localhost:8080`-->
-<html>
-  <form method="POST" action="/submit">
-    <input type="text" name="email" />
-    <input type="submit" value="Submit" />
-  </form>
-</html>
-```
-
-```javascript
-cy.visit('http://localhost:8080')
-cy.get('form').submit() // submit the form!
-```
-
-If your back end server handling the `/submit` route does a `30x` redirect to a
-different superdomain, you will get a cross-origin error.
-
-```javascript
-// imagine this is some node / express code
-// on your localhost:8080 server
-
-app.post('/submit', (req, res) => {
-  // redirect the browser to google.com
-  res.redirect('https://google.com')
-})
-```
-
-A common use case for this is Single sign-on (SSO). In that situation you may
-`POST` to a different server and are redirected elsewhere (typically with the
-session token in the URL).
-
-If that's the case, you can still test this behavior with
-[`cy.request()`](/api/commands/request). [`cy.request()`](/api/commands/request)
-is **NOT bound to CORS or same-origin policy**.
-
-In fact we can likely bypass the initial visit altogether and `POST` directly to
-your SSO server.
-
-```javascript
-cy.request('POST', 'https://sso.corp.com/auth', {
-  username: 'foo',
-  password: 'bar',
-}).then((response) => {
-  // pull out the location redirect
-  const loc = response.headers['Location']
-
-  // parse out the token from the url (assuming its in there)
-  const token = parseOutMyToken(loc)
-
-  // do something with the token that your web application expects
-  // likely the same behavior as what your SSO does under the hood
-  // assuming it handles query string tokens like this
-  cy.visit('http://localhost:8080?token=' + token)
-
-  // if you don't need to work with the token you can sometimes
-  // visit the location header directly
-  cy.visit(loc)
-})
-```
-
-If you still want to be able to be redirected to your SSO server, you can read
-about
-[disabling web security](/guides/guides/web-security#Disabling-Web-Security).
-
-### JavaScript Redirects
-
-When we say JavaScript Redirects we are talking about any kind of code that does
-something like this:
-
-```javascript
-window.location.href = 'http://some.superdomain.com'
-```
-
-This is probably the hardest situation to test because it's usually happening
-due to another cause. You will need to figure out why your JavaScript code is
-redirecting. Perhaps you're not logged in, and you need to handle that setup
-elsewhere. Perhaps you're using a Single sign-on (SSO) server and you can read
-the previous section about working around that.
-
-If you want to continue using the code to navigate to a different superdomain,
-then you might want to read about
-[disabling web security](/guides/guides/web-security#Disabling-Web-Security).
-
-## Disabling Web Security
-
-So if you cannot work around any of the issues using the suggested workarounds
-above, you may want to disable web security.
-
-One last thing to consider here is that every once in a while we discover bugs
-in Cypress that lead to cross-origin errors that can otherwise be fixed. If you
-think you're experiencing a bug,
-[open an issue](https://github.com/cypress-io/cypress/issues/new/choose).
-
-<Alert type="warning">
-
-<strong class="alert-header">Chrome only</strong>
-
-Disabling web security is only supported in Chrome-based browsers. Settings in
-`chromeWebSecurity` will have no effect in other browsers. We will log a warning
-in this case.
-
-<DocsImage src="/img/guides/web-security/chrome-web-security-stdout-warning.jpg" alt='chromeWebSecurity warning in stdout'></DocsImage>
-
-If you rely on disabling web security, you will not be able to run tests on
-browsers that do not support this feature.
-
-</Alert>
-
-### Set `chromeWebSecurity` to `false`
-
-Setting `chromeWebSecurity` to `false` in Chrome-based browsers allows you to do
-the following:
-
-- Display insecure content
-- Navigate to any superdomain without cross-origin errors
-- Access cross-origin iframes that are embedded in your application
-
-One thing you may notice though is that Cypress still enforces visiting a single
-superdomain with [`cy.visit()`](/api/commands/visit), but there is an
-[issue open](https://github.com/cypress-io/cypress/issues/944) to change this
-restriction.
-
-Still here? That's cool, let's disable web security!
-
-#### Set `chromeWebSecurity` to `false` in the [Cypress configuration](/guides/references/configuration)
-
-:::cypress-config-example
-
-```js
-{
-  chromeWebSecurity: false
-}
-```
-
-:::
diff --git a/content/guides/references/configuration.md b/content/guides/references/configuration.md
index 7c9a9b6bd8..7513e8d05e 100644
--- a/content/guides/references/configuration.md
+++ b/content/guides/references/configuration.md
@@ -140,7 +140,7 @@ For more options regarding screenshots, view the
 
 | Option                  | Default                              | Description                                                                                                                                                                                                                                                                                                                                                        |
 | ----------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `chromeWebSecurity`     | `true`                               | Whether to enable Chromium-based browser's Web Security for same-origin policy and insecure mixed content. [Read more about Web Security](/guides/guides/web-security).                                                                                                                                                                                            |
+| `chromeWebSecurity`     | `true`                               | Whether to enable Chromium-based browser's Web Security for same-origin policy and insecure mixed content.                                                                                                                                                            |
 | `blockHosts`            | `null`                               | A String or Array of hosts that you wish to block traffic for. [Please read the notes for examples on using this.](#blockHosts)                                                                                                                                                                                                                                    |
 | `modifyObstructiveCode` | `true`                               | Whether Cypress will search for and replace obstructive JS code in `.js` or `.html` files. [Please read the notes for more information on this setting.](#modifyObstructiveCode)                                                                                                                                                                                   |
 | `userAgent`             | `null`                               | Enables you to override the default user agent the browser sends in all request headers. User agent values are typically used by servers to help identify the operating system, browser, and browser version. See [User-Agent MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent) for example user agent values.              |
diff --git a/content/guides/references/error-messages.md b/content/guides/references/error-messages.md
index 237ed811b9..ca46919c36 100644
--- a/content/guides/references/error-messages.md
+++ b/content/guides/references/error-messages.md
@@ -459,8 +459,6 @@ it('does not forget to return a promise', () => {
 
 ::include{file=partials/single-domain-workaround.md}
 
-See our [Web Security](/guides/guides/web-security#Limitations) documentation.
-
 ### <Icon name="exclamation-triangle" color="red"></Icon> `cy.visit()` failed because you are attempting to visit a different origin domain
 
 ::include{file=partials/single-domain-workaround.md}
@@ -475,9 +473,6 @@ You can visit urls that are of different origin across different tests, so you
 may consider splitting your `cy.visit()` of different origin domains into
 separate tests.
 
-See our [Web Security](/guides/guides/web-security#Limitations) documentation
-for more information and workarounds.
-
 ### <Icon name="exclamation-triangle" color="red"></Icon> `Cypress.addParentCommand()` / `Cypress.addDualCommand()` / `Cypress.addChildCommand()` has been removed and replaced by `Cypress.Commands.add()`
 
 In version [0.20.0](/guides/references/changelog), we removed the commands for
@@ -540,10 +535,6 @@ The version of Mocha was upgraded with Cypress 4.0. Mocha 3+ no longer allows
 returning a promise and invoking a done callback. Read more about it in the
 [4.0 migration guide](/guides/references/migration-guide#Mocha-upgrade).
 
-### <Icon name="exclamation-triangle" color="red"></Icon> Passing `cy.route({stub: false})` or `cy.server({stub: false})` is now deprecated.
-
-You can safely remove: `{stub: false}`.
-
 ### <Icon name="exclamation-triangle" color="red"></Icon> CypressError: Timed out retrying: Expected to find element: ‘…’, but never found it. Queried from element: <…>
 
 If you get this error in a case where the element is definitely visible in the
diff --git a/content/guides/references/experiments.md b/content/guides/references/experiments.md
index 8a2028976a..f34d65523c 100644
--- a/content/guides/references/experiments.md
+++ b/content/guides/references/experiments.md
@@ -56,7 +56,7 @@ configuration object:
 
 | Version                                       | Changes                                                                                                                      |
 | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
-| [11.0.0](/guides/references/changelog#11-0-0) | Removed `experimentalSessionAndOrigin`.                                                                                      |
+| [12.0.0](/guides/references/changelog#12-0-0) | Removed `experimentalSessionAndOrigin` and made it the default behavior.                                                     |
 | [10.8.0](/guides/references/changelog#10-8-0) | Added `experimentalWebKitSupport`.                                                                                           |
 | [10.6.0](/guides/references/changelog#10-6-0) | Added support for `experimentalSingleTabRunMode`.                                                                            |
 | [10.4.0](/guides/references/changelog#10-4-0) | Added support for `experimentalModifyObstructiveThirdPartyCode`.                                                             |
diff --git a/content/guides/references/legacy-configuration.md b/content/guides/references/legacy-configuration.md
index 20a4d89fe4..3bc8f626cf 100644
--- a/content/guides/references/legacy-configuration.md
+++ b/content/guides/references/legacy-configuration.md
@@ -117,7 +117,7 @@ For more options regarding screenshots, view the
 
 | Option                  | Default                              | Description                                                                                                                                                                                                                                                                                                                                                        |
 | ----------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `chromeWebSecurity`     | `true`                               | Whether to enable Chromium-based browser's Web Security for same-origin policy and insecure mixed content. [Read more about Web Security](/guides/guides/web-security).                                                                                                                                                                                            |
+| `chromeWebSecurity`     | `true`                               | Whether to enable Chromium-based browser's Web Security for same-origin policy and insecure mixed content.                                                                                                                                                                                                                                                         |
 | `blockHosts`            | `null`                               | A String or Array of hosts that you wish to block traffic for. [Please read the notes for examples on using this.](#blockHosts)                                                                                                                                                                                                                                    |
 | `firefoxGcInterval`     | `{ "runMode": 1, "openMode": null }` | (Firefox 79 and below only) Controls whether Cypress forces Firefox to run garbage collection (GC) cleanup and how frequently. During [cypress run](/guides/guides/command-line#cypress-run), the default value is `1`. During [cypress open](/guides/guides/command-line#cypress-open), the default value is `null`. See full details [here](#firefoxGcInterval). |
 | `modifyObstructiveCode` | `true`                               | Whether Cypress will search for and replace obstructive JS code in `.js` or `.html` files. [Please read the notes for more information on this setting.](#modifyObstructiveCode)                                                                                                                                                                                   |
diff --git a/content/guides/references/trade-offs.md b/content/guides/references/trade-offs.md
index ed847af66f..c0297bb274 100644
--- a/content/guides/references/trade-offs.md
+++ b/content/guides/references/trade-offs.md
@@ -268,91 +268,3 @@ app.listen(8081, () => {})
 This avoids ever needing a second open browser, but still gives you an
 end-to-end test that provides 100% confidence that the two clients can
 communicate with each other.
-
-### Same-origin
-
-::include{file=partials/single-domain-workaround.md}
-
-Each test is limited to only visiting the domains that are determined to be of
-the same-origin rule.
-
-What is same-origin? Two URLs have the same origin if the protocol, port (if
-specified), and host are the same for both. Cypress automatically handles hosts
-of the same superdomain by injecting the
-[`document.domain`](https://developer.mozilla.org/en-US/docs/Web/API/Document/domain)
-property into the visited `text/html` pages, so a host of the same superdomain
-is considered fine.
-
-Given the URLs below, all have the same-origin compared to
-`https://www.cypress.io`.
-
-- `https://cypress.io`
-- `https://docs.cypress.io`
-- `https://example.cypress.io/commands/querying`
-
-The URLs below, however, will have different origins compared to
-`https://www.cypress.io`.
-
-- `http://www.cypress.io` (Different protocol)
-- `https://docs.cypress.io:81` (Different port)
-- `https://www.auth0.com/` (Different host of different superdomain)
-
-The `http://localhost` URLs differ if their ports are different. For example,
-the `http://localhost:3000` URL is considered to be a different origin from the
-`http://localhost:8080` URL.
-
-The rules are:
-
-- <Icon name="exclamation-triangle" color="red"></Icon> You **cannot**
-  [visit](/api/commands/visit) two domains of different origin in the same test.
-- <Icon name="check-circle" color="green"></Icon> You **can**
-  [visit](/api/commands/visit) two or more domains of different origin in
-  **different** tests.
-
-```javascript
-it('navigates', () => {
-  cy.visit('https://www.cypress.io')
-  cy.visit('https://docs.cypress.io') // yup all good
-})
-```
-
-```javascript
-it('navigates', () => {
-  cy.visit('https://apple.com')
-  cy.visit('https://google.com') // this will error
-})
-```
-
-```javascript
-it('navigates', () => {
-  cy.visit('https://apple.com')
-})
-
-// split visiting different origin in another test
-it('navigates to new origin', () => {
-  cy.visit('https://google.com') // yup all good
-})
-```
-
-This limitation exists because Cypress switches to the domain under each
-specific test when it runs.
-
-#### Other workarounds
-
-There are other ways of testing the interaction between 2 superdomains. Because
-the browser has a natural security barrier called `origin policy` this means
-that state like `localStorage`, `cookies`, `service workers` and many other APIs
-are not shared between them anyways.
-
-So what you do on one site does not directly affect another.
-
-As a best practice, you should not visit or interact with a 3rd party service
-not under your control. However, there are exceptions! If your organization uses
-Single Sign On (SSO) or OAuth then you might involve a 3rd party service other
-than your superdomain.
-
-We've written several other guides specifically about handling this situation.
-
-- [Best Practices: Visiting external sites](/guides/references/best-practices#Visiting-external-sites)
-- [Web Security: Common Workarounds](/guides/guides/web-security#Common-Workarounds)
-- [Recipes: Logging In - Single Sign On](/examples/examples/recipes#Logging-In)
diff --git a/content/guides/tooling/IDE-integration.md b/content/guides/tooling/IDE-integration.md
index 4dc761c9f6..2b2f3f1855 100644
--- a/content/guides/tooling/IDE-integration.md
+++ b/content/guides/tooling/IDE-integration.md
@@ -43,9 +43,8 @@ with Cypress.
 ### Visual Studio Code
 
 - [Cypress Fixture-IntelliSense](https://marketplace.visualstudio.com/items?itemName=JosefBiehler.cypress-fixture-intellisense):
-  Supports your [cy.fixture()](/api/commands/fixture) and
-  [`cy.route(..., "fixture:")`](/api/commands/route) commands by providing
-  intellisense for existing fixtures.
+  Supports your [cy.fixture()](/api/commands/fixture) by providing intellisense
+  for existing fixtures.
 - [Cypress Helper](https://marketplace.visualstudio.com/items?itemName=Shelex.vscode-cy-helper):
   Various helpers and commands for integration with Cypress.
 - [Cypress Snippets](https://marketplace.visualstudio.com/items?itemName=andrew-codes.cypress-snippets):
diff --git a/cypress/fixtures/sidebar-overrides.json b/cypress/fixtures/sidebar-overrides.json
index 6776822221..035927827c 100644
--- a/cypress/fixtures/sidebar-overrides.json
+++ b/cypress/fixtures/sidebar-overrides.json
@@ -23,7 +23,6 @@
     "/api/cypress-api/screenshot-api": "Cypress.Screenshot",
     "/api/cypress-api/keyboard-api": "Cypress.Keyboard",
     "/api/cypress-api/selector-playground-api": "Cypress.SelectorPlayground",
-    "/api/cypress-api/cypress-server": "Cypress.Server",
     "/api/cypress-api/arch": "Cypress.arch",
     "/api/cypress-api/browser": "Cypress.browser",
     "/api/cypress-api/config": "Cypress.config",