diff --git a/docs/docs/adding-page-transitions.md b/docs/docs/adding-page-transitions.md
deleted file mode 100644
index ab28eb0db66d1..0000000000000
--- a/docs/docs/adding-page-transitions.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Adding Page Transitions
----
-
-Page transitions give users a better experience when navigating between pages. There are a number of ways to add them to your Gatsby site.
-
-
diff --git a/docs/docs/api-files.md b/docs/docs/api-files.md
deleted file mode 100644
index dab584c7073ca..0000000000000
--- a/docs/docs/api-files.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: API Files
----
-
-Gatsby uses 4 files in the root of your project to configure your site and control its behavior. Both sites and plugins may implement these files. All of these files are optional.
-
-- [gatsby-config.js/gatsby-config.ts](/docs/reference/config-files/gatsby-config/) - Enables plugins, defines common site data, and contains other site configuration that integrates with Gatsby's GraphQL data layer.
-- [gatsby-browser.jsx/gatsby-browser.tsx](/docs/reference/config-files/gatsby-browser/) - Gives you control over Gatsby's behavior in the browser. For example, responding to a user changing routes, or calling a function when the user first opens any page.
-- [gatsby-node.js/gatsby-node.ts](/docs/reference/config-files/gatsby-node/) - Allows you to respond to events in the Gatsby build cycle. For example, adding pages dynamically, editing GraphQL nodes as they are created, or performing an action after a build is complete.
-- [gatsby-ssr.jsx/gatsby-ssr.tsx](/docs/reference/config-files/gatsby-ssr) - Exposes Gatsby's server-side rendering process so you can control how it builds your HTML pages.
diff --git a/docs/docs/api-specification.md b/docs/docs/api-specification.md
deleted file mode 100644
index c7e874d051f0d..0000000000000
--- a/docs/docs/api-specification.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: API Specification
----
-
-Gatsby's APIs are tailored conceptually to some extent after React.js to improve the coherence between the two systems.
-
-The two top priorities of the API are : a) enable a broad and robust plugin ecosystem and b) build on top of that a broad and robust theme ecosystem.
-
-## Prerequisites
-
-If you’re not familiar with Gatsby’s lifecycle, see the overview [Gatsby Lifecycle APIs](/docs/conceptual/gatsby-lifecycle-apis/).
-
-## Plugins
-
-Plugins can extend Gatsby in many ways:
-
-- Sourcing data (e.g. from the filesystem or an API or a database)
-- Transforming data from one type to another (e.g. a markdown file to HTML)
-- Creating pages (e.g. a directory of markdown files all gets turned into pages with URLs derived from their file names).
-- Modifying webpack config (e.g. for styling options, adding support for other compile-to-js languages)
-- Adding things to the rendered HTML (e.g. meta tags, analytics JS snippets like Google Analytics)
-- Writing out things to build directory based on site data (e.g. service worker, sitemap, RSS feed)
-
-A single plugin can use multiple APIs to accomplish its purpose. E.g. the plugin for the CSS-in-JS library [Glamor](/plugins/gatsby-plugin-glamor/):
-
-1. modifies the webpack config to add its plugin
-2. adds a Babel plugin to replace React's default createElement
-3. modifies server rendering to extract out the critical CSS for each rendered page and inline the CSS in the `` of that HTML page.
-
-Plugins can also depend on other plugins. [The Sharp plugin](/plugins/gatsby-plugin-sharp/) exposes a number of high-level APIs for transforming images that several other Gatsby image plugins depend on. [gatsby-transformer-remark](/plugins/gatsby-transformer-remark/) does basic markdown->HTML transformation but exposes an API to allow other plugins to intervene in the conversion process e.g. [gatsby-remark-prismjs](/plugins/gatsby-remark-prismjs/) which adds highlighting to code blocks.
-
-Transformer plugins are decoupled from source plugins. Transformer plugins look at the media type of new nodes created by source plugins to decide if they can transform it or not. Which means that a markdown transformer plugin can transform markdown from any source without any other configuration e.g. from a file, a code comment, or external service like Trello which supports markdown in some of its data fields.
-
-See [the full list of (official only for now — adding support for community plugins later) plugins](/docs/plugins/).
-
-## API
-
-### Concepts
-
-- _Page_ — a site page with a pathname, a template component, and optional GraphQL query.
-- _Page Component_ — React.js component that renders a page and can optionally specify a GraphQL query
-- _Component extensions_ — extensions that are resolvable as components. `.js` and `.jsx` are supported by core. But plugins can add support for other compile-to-js languages.
-- _Dependency_ — Gatsby automatically tracks dependencies between different objects e.g. a page can depend on certain nodes. This allows for hot reloading, caching, incremental rebuilds, etc.
-- _Node_ — a data object
-- _Node Field_ — a field added by a plugin to a node that it doesn't control
-- _Node Link_ — a connection between nodes that gets converted to GraphQL relationships. Can be created in a variety of ways as well as automatically inferred. Parent/child links from nodes and their transformed derivative nodes are first class links.
-
-_More definitions and terms are defined in the [Glossary](/docs/glossary/)_
-
-### Operators
-
-- _Create_ — make a new thing
-- _Get_ — get an existing thing
-- _Delete_ — remove an existing thing
-- _Replace_ — replace an existing thing
-- _Set_ — merge into an existing thing
-
-### Extension APIs
-
-Gatsby has multiple processes. The most prominent is the "bootstrap" process. It has several subprocesses. One tricky part to their design is that they run both once during the initial bootstrap but also stay alive during development to continue to respond to changes. This is what drives hot reloading that all Gatsby data is "alive" and reacts to changes in the environment.
-
-The bootstrap process is as follows:
-
-load site config -> load plugins -> source nodes -> transform nodes -> create GraphQL schema -> create pages -> compile component queries -> run queries -> fin
-
-Once the initial bootstrap is finished, a `webpack-dev-server` and express server are started for serving files for the development workflow with live updates. For a production build, Gatsby skips the development server and instead builds the CSS, then JavaScript, then static HTML with webpack.
-
-During these processes there are various extension points where plugins can intervene. All major processes have an `onPre` and `onPost` e.g. `onPreBootstrap` and `onPostBootstrap` or `onPreBuild` or `onPostBuild`. During bootstrap plugins can respond at various stages to APIs like `onCreatePages`, `onCreateBabelConfig`, and `onSourceNodes`.
-
-At each extension point, Gatsby identifies the plugins which implement the API and calls them in serial following their order in the site's `gatsby-config.js`.
-
-In addition to extension APIs in a node, plugins can also implement extension APIs in the server rendering process and the browser e.g. `onClientEntry` or `onRouteUpdate`.
-
-The three main inspirations for this API and spec are React.js' API specifically [@leebyron's email on the React API](https://gist.github.com/vjeux/f2b015d230cc1ab18ed1df30550495ed), this talk ["How to Design a Good API and Why it Matters" by Joshua Bloch](https://www.youtube.com/watch?v=heh4OeB9A-c) who designed many parts of Java, and [Hapi.js](https://hapi.dev/api)' plugin design.
diff --git a/docs/docs/babel-plugin-macros.md b/docs/docs/babel-plugin-macros.md
deleted file mode 100644
index 6b0f0331d866a..0000000000000
--- a/docs/docs/babel-plugin-macros.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Using Babel Plugin Macros
----
-
-Gatsby includes a powerful new way of applying compile-time code transformations, [Babel macros](https://github.com/kentcdodds/babel-plugin-macros)! Macros are like Babel plugins, but instead of adding them to your `.babelrc`, you import them in the file you want to use them. This has two big advantages:
-
-- No confusion about where a non-standard syntax is coming from. Macros are explicitly imported wherever they are used.
-- No configuration files. Macros are included directly in your code as needed.
-
-Like Babel plugins, macros run only at compile time. They are not included in the public JavaScript bundle. As such, macros have no effect on your code beyond the transformations they apply.
-
-## Installing macros
-
-Just like plugins, many macros are published as npm packages. By convention, they are named by their function, followed by `.macro`.
-
-For example, [`preval.macro`](https://www.npmjs.com/package/preval.macro) is a macro that pre-evaluates JavaScript code. You can install it by running:
-
-```shell
-npm install --save-dev preval.macro
-```
-
-Some macros are instead included in larger packages. To install and use them, refer to their documentation.
-
-## Using macros
-
-To use an installed macro, import it in your code like so:
-
-```javascript
-import preval from "preval.macro"
-```
-
-You can then use the imported variable however the macro's documentation says.
-`preval.macro` is used as a template literal tag:
-
-```javascript
-import preval from "preval.macro"
-const x = preval`module.exports = 1` // highlight-line
-```
-
-When building your project this code will be transformed into:
-
-```javascript
-const x = 1
-```
-
-## Discovering available macros
-
-Take a look at the [Awesome babel macros](https://github.com/jgierer12/awesome-babel-macros) list to find available macros you can use. Additionally, this list contains helpful resources for using macros and developing them yourself.
diff --git a/docs/docs/basic-hardware-software-requirements.md b/docs/docs/basic-hardware-software-requirements.md
deleted file mode 100644
index 455baf70221b5..0000000000000
--- a/docs/docs/basic-hardware-software-requirements.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: Basic Hardware and Software Requirements
----
-
-Find the latest hardware and software requirements for building with Gatsby. Note: this doc will evolve as the framework evolves, so if you find something that's outdated please [open an issue with your findings](/contributing/how-to-file-an-issue/).
-
-## Operating Systems
-
-- macOS Sierra or later (10.12)
-- Windows 10 ([setup instructions](/docs/how-to/local-development/gatsby-on-windows/))
-- Linux ([multiple distributions](/docs/how-to/local-development/gatsby-on-linux/))
-
-### Platform specific issues
-
-- Gatsby (or at least the [sharp library](https://sharp.pixelplumbing.com/) which is used in Gatsby's image pipeline) will not work on Linux if the CPU does not support SSE4.2 (e.g. CPUs pre-2012). If you're experiencing problems, check if your platform is supported by `sharp`.
-
-## Memory
-
-This will be variable depending on the size of your site. Gatsby sites have been known to work from 500mb to 1GB of RAM.
-
-## Node.js ecosystem
-
-To develop with Gatsby, you'll need to install:
-
-- Node.js 14.15.0 (LTS) or higher
-- [npm](https://www.npmjs.com/) or [Yarn 1](https://classic.yarnpkg.com/lang/en/) package manager to install the [Gatsby CLI](/docs/reference/gatsby-cli/) and site dependencies.
- - npm is recommended for most developers.
- - Yarn is used for authoring Gatsby themes.
- - Yarn is also used for developing Gatsby itself, as well as its websites.
- - Note: while Yarn 2 should work with Gatsby's core plugins, some 3rd-party plugins do not.
- - There's a [command to tell the Gatsby CLI which package manager to use](/docs/reference/gatsby-cli/#how-to-change-your-default-package-manager-for-your-next-project).
-
-It's possible to use Gatsby without the CLI, which relies on public GitHub access. [See docs for more info](/docs/using-gatsby-professionally/using-gatsby-professionally/setting-up-gatsby-without-gatsby-new/).
-
-## Browser versions
-
-- This is the same as [React DOM](https://reactjs.org/docs/react-dom.html#browser-support), as Gatsby uses React to build websites.
- - IE9+ (with polyfills) and popular modern browsers.
-- See more on [browser support](/docs/how-to/custom-configuration/browser-support/).
diff --git a/docs/docs/building-an-e-commerce-site.md b/docs/docs/building-an-e-commerce-site.md
deleted file mode 100644
index 410fc1a00cd24..0000000000000
--- a/docs/docs/building-an-e-commerce-site.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Building an E-commerce Site
----
-
-The speed and performance of sites built with Gatsby make it a great tool for building e-commerce sites. There are existing plugins for connecting services like [Shopify](/plugins/gatsby-source-shopify/) and [Snipcart](/plugins/gatsby-plugin-snipcart/) to Gatsby, and this section contains reference guides to help get things setup.
-
-To see examples of e-commerce sites built with Gatsby, check out the [showcase](/showcase/?filters%5B0%5D=E-commerce).
-
-
-
-_You can also check out the ["Making an E-commerce Site with Stripe" tutorial](/tutorial/ecommerce-tutorial/) for more information._
diff --git a/docs/docs/conceptual-guide.md b/docs/docs/conceptual-guide.md
deleted file mode 100644
index f64dd0c72f61e..0000000000000
--- a/docs/docs/conceptual-guide.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Conceptual Guide
----
-
-Read high-level overviews of important Gatsby concepts and philosophies.
-
-
diff --git a/docs/docs/customization.md b/docs/docs/customization.md
deleted file mode 100644
index 7bb56ccc02de4..0000000000000
--- a/docs/docs/customization.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Custom Configuration
----
-
-Sometimes you may find yourself in a situation where Gatsby's default configuration just isn't quite what you need for your site. If you should find yourself in this situation, have no fear my friend, you can customize Gatsby's config for `babel` and `webpack`. You can also customize `html.js`, the React component used to generate the initial HTML file of your build. You'll also find guides on how to get custom environment variables into your website, as well how to proxy API requests in development so your API calls aren't interpreted by your server as static assets.
-
-
diff --git a/docs/docs/data-storage-redux.md b/docs/docs/data-storage-redux.md
deleted file mode 100644
index 1538f70baaa62..0000000000000
--- a/docs/docs/data-storage-redux.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Data Storage (Redux)
----
-
-During Gatsby's bootstrap & build phases, the state is stored and manipulated using the [Redux](https://redux.js.org/) library. The key purpose of using Redux in Gatsby internals is to centralize all of the state logic. Reviewing the Gatsby [reducers](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby/src/redux/reducers) and [actions](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby/src/redux/actions) folders gives a comprehensive picture of what state manipulations are possible.
-
-## Store
-
-The namespaces in Gatsby's Redux store are a great overview of the Gatsby internals, here are a few:
-
-- **[Nodes](/docs/reference/graphql-data-layer/node-interface/)** - All data that’s added to Gatsby is modeled using nodes. Nodes are most commonly added by Source plugins such as `gatsby-source-filesystem`.
-- **[Schema](/docs/schema-generation/)** - GraphQL [schema](/docs/glossary#schema) [inferred](/docs/glossary#inference) from Nodes, available for querying by page and static queries.
-- **[Pages](/docs/gatsby-internals-terminology/#page)** - A `Map` of page paths to page objects. Objects made via [Page Creation](/docs/page-creation) contain information needed to render a page such as component file path, page query and context.
-- **[Components](/docs/gatsby-internals-terminology/#component)** - A `Map` of component file paths to page objects.
-- **[Static Query Components](/docs/static-vs-normal-queries/#keeping-track-of-site-queries-during-build-in-redux-stores)** - A `Map` of any components detected with a [static query](/docs/how-to/querying-data/static-query/).
-- **Jobs** - Long-running and CPU-intensive processes, generally started as a side effect to a GraphQL query. Gatsby doesn’t finish its process until all jobs are ended.
-- **webpack** - Config for the [webpack](/docs/webpack-and-ssr/) bundler which handles code optimization and splitting of delivered JavaScript bundles.
-
-The Gatsby [Redux index file](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby/src/redux/index.ts) has two key exports, `store` and `emitter`. Throughout the bootstrap and build phases, `store` is used to get the current state and dispatch actions, while `emitter` is used to register listeners for particular actions. The store is also made available to Gatsby users through the [Node APIs](/docs/reference/config-files/gatsby-node/).
-
-## Actions
-
-Actions dispatched in the store cause state changes through the reducers and also trigger listeners registered for that action on a [mitt](https://www.npmjs.com/package/mitt) `emitter`. While the `subscribe` Redux store method is typically used to connect a web framework like React, Gatsby only uses the `subscribe` method to connect the `emitter`.
-
-The [Gatsby actions](/docs/reference/config-files/actions/) are all either internal, public or restricted. The public actions, and a context relevant subset of the restricted actions, are available to users through the [Node APIs](/docs/reference/config-files/gatsby-node/).
-
-### Example action journey for `createRedirect`
-
-Gatsby actions have a similar journey through defining, exposing and dispatching. This section follows the [createRedirect](/docs/reference/config-files/actions/#createRedirect) public action:
-
-- **Reducer case** - The redirects reducer will catch actions with a type `CREATE_REDIRECT` and make the necessary state manipulation.
-
-- **Side effect** - An `emitter` listener is registered for the `CREATE_REDIRECT` action type.
-
-- **Action creator** - An action creator, `createRedirect`, is defined in the public actions file. The action has a payload, the information needed to complete the action, and a type, the string that identifies this particular action.
-
-- **Expose bound action creator** - `createRedirect` is one of the public actions made available to all of the [Node APIs](/docs/reference/config-files/gatsby-node/). A collection of public actions and the restricted actions available to the called API are bound to the Redux store dispatch. The bound action collection is then passed when calling the user's API function.
-
-- **Dispatch** - Here is an example of the `createRedirect` call that a Gatsby user could make with the [createPages](/docs/reference/config-files/gatsby-node/#createPages) API in their project's [gatsby-node.js](/docs/reference/config-files/gatsby-node/) file:
-
-```javascript:title=gatsby-node.js
-module.exports = {
- createPages: ({ actions }) => {
- const { createRedirect } = actions
- createRedirect({
- fromPath: "/legacy-path",
- toPath: "/current-path",
- })
- },
-}
-```
-
-By walking through an action scenario in detail, you can hopefully understand more about Gatsby's internals using Redux.
-
-## Additional resources
-
-- [Behind the Scenes: What Makes Gatsby Great](/blog/2019-04-02-behind-the-scenes-what-makes-gatsby-great/)
-- [Gatsby Jargon](/docs/conceptual/gatsby-jargon/)
diff --git a/docs/docs/debugging-replace-renderer-api.md b/docs/docs/debugging-replace-renderer-api.md
deleted file mode 100644
index ef87094e0750a..0000000000000
--- a/docs/docs/debugging-replace-renderer-api.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: Debugging replaceRenderer API
----
-
-## Prerequisites
-
-If you’re not familiar with Gatsby’s lifecycle, see the overview [Gatsby Lifecycle APIs](/docs/conceptual/gatsby-lifecycle-apis/).
-
-## What is the `replaceRenderer` API?
-
-The `replaceRenderer` API is one of [Gatsby's Server Side Rendering (SSR) extension APIs](/docs/reference/config-files/gatsby-ssr/#replaceRenderer). This API is called when you run `gatsby build` and is used to customize how Gatsby renders your static content. It can be implemented by any Gatsby plugin or your `gatsby-ssr.js` file - adding support for Redux, CSS-in-JS libraries or any code that needs to change Gatsby's default HTML output.
-
-## Why does it cause build errors?
-
-If multiple plugins implement `replaceRenderer` in your project, only the last plugin implementing the API can be called - which will break your site builds.
-
-Note that `replaceRenderer` is only used during the build lifecycle. It won't cause problems as you work on your site with the develop script.
-
-If multiple plugins implement `replaceRenderer`, the build script will warn you:
-
-```text
-warning replaceRenderer API found in these plugins:
-warning plugin-name-a, default-site-plugin
-warning This might be an error, see: https://www.gatsbyjs.com/docs/debugging-replace-renderer-api/
-
-warning Duplicate replaceRenderer found, skipping gatsby-ssr.js for plugin: plugin-name-a
-```
-
-Note that `default-site-plugin` refers to your local `gatsby-ssr.js` file, if this file exists it will always be used in favor of `gatsby-ssr.js` from other plugins.
-
-## Fixing `replaceRenderer` build errors
-
-If you see errors during your build, you can fix them with the following steps.
-
-### 1. Identify the plugins using `replaceRenderer`
-
-Your error message should list which plugins implement `replaceRenderer`:
-
-```text
-warning replaceRenderer API found in these plugins:
-warning plugin-name-a, default-site-plugin
-```
-
-In this example, your `gatsby-ssr.js` file and `plugin-name-a` are both using `replaceRenderer`.
-
-### 2. Copy the plugins' `replaceRenderer` functionality to your site's `gatsby-ssr.js` file
-
-You'll need to override your plugins' `replaceRenderer` code in your `gatsby-ssr.js` file. This step will be different for each project, keep reading to see an example.
-
-## Example
-
-### Initial setup
-
-In this example project you're using [Redux](https://github.com/gatsbyjs/gatsby/tree/master/examples/using-redux) and [Gatsby's Styled Components plugin](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-plugin-styled-components).
-
-```js:title=gatsby-config.js
-module.exports = {
- plugins: [`gatsby-plugin-styled-components`],
-}
-```
-
-`gatsby-ssr.js` (based on the [using Redux example](https://github.com/gatsbyjs/gatsby/blob/master/examples/using-redux/gatsby-ssr.js))
-
-```jsx:title=gatsby-ssr.js
-import React from "react"
-import { Provider } from "react-redux"
-import { renderToString } from "react-dom/server"
-
-import createStore from "./src/state/createStore"
-
-exports.replaceRenderer = ({ bodyComponent, replaceBodyHTMLString }) => {
- const store = createStore()
-
- const ConnectedBody = () => {bodyComponent}
- replaceBodyHTMLString(renderToString())
-}
-```
-
-Note that the Styled Components plugin uses `replaceRenderer`, and the code in `gatsby-ssr.js` also uses `replaceRenderer`.
-
-### Fixing the `replaceRenderer` error
-
-Your `gatsby-config.js` file will remain unchanged. However, your `gatsby-ssr.js` file will update to include the [`replaceRenderer` functionality from the Styled Components plugin](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-plugin-styled-components/src/gatsby-ssr.js)
-
-```jsx:title=gatsby-ssr.js
-import React from "react"
-import { Provider } from "react-redux"
-import { renderToString } from "react-dom/server"
-import { ServerStyleSheet, StyleSheetManager } from "styled-components"
-import createStore from "./src/state/createStore"
-
-exports.replaceRenderer = ({
- bodyComponent,
- replaceBodyHTMLString,
- setHeadComponents,
-}) => {
- const sheet = new ServerStyleSheet()
- const store = createStore()
-
- const app = () => (
-
-
- {bodyComponent}
-
-
- )
- replaceBodyHTMLString(renderToString())
- setHeadComponents([sheet.getStyleElement()])
-}
-```
-
-Now `gatsby-ssr.js` implements the Styled Components and Redux functionality using one `replaceRenderer` instance. Run `npm run build` and the site will build correctly.
-
-All the code from this example is [available on GitHub](https://github.com/m-allanson/gatsby-replace-renderer-example/commits/master).
diff --git a/docs/docs/deploying-to-bip.md b/docs/docs/deploying-to-bip.md
deleted file mode 100644
index 5a147abc2f079..0000000000000
--- a/docs/docs/deploying-to-bip.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Deploying to Bip
----
-
-[Bip](https://bip.sh) is a commercial hosting service which provides zero downtime deployment, a global CDN, SSL, unlimited bandwidth and more for Gatsby websites. Plans are available on a pay as you go, per domain basis.
-
-The following guide will show you how to deploy your Gatsby site to Bip in just a couple simple steps.
-
-## Prerequisites
-
-- You have a Gatsby project ready to deploy and share with the world. If you need a project, use the [Quick Start](/docs/quick-start) before continuing.
-- You have the Bip CLI installed, along with a Bip account and domain ready to use. Visit the [Bip Get Started guide](https://bip.sh/getstarted) for further instructions.
-
-## Step 1: Initial setup
-
-You'll first need to initialize your project with Bip. This only needs to be done once.
-
-```shell
-bip init
-```
-
-Follow the prompts, where you'll be asked which domain you'd like to deploy to. Bip will detect that you're using Gatsby, and set project settings like the source file directory automatically.
-
-## Step 2: Deploy
-
-You're now ready to deploy your website. To do so, run:
-
-```shell
-gatsby build && bip deploy
-```
-
-That's it! After a few moments, your website will be deployed.
-
-## References:
-
-- [Bip Get Started Guide](https://bip.sh/getstarted)
diff --git a/docs/docs/files-gatsby-looks-for-in-a-plugin.md b/docs/docs/files-gatsby-looks-for-in-a-plugin.md
deleted file mode 100644
index a72a9158fad3a..0000000000000
--- a/docs/docs/files-gatsby-looks-for-in-a-plugin.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Files Gatsby Looks for in a Plugin
----
-
-## What files does Gatsby look for in a plugin?
-
-All files are optional unless specifically marked as required.
-
-- `package.json` — [required] this can be an empty object (`{}`) for local plugins.
- - `name` is used to identify the plugin when it mutates Gatsby’s GraphQL data structure
- - if `name` isn’t set, the folder name for the plugin is used
- - `main` is the [name of the file that will be loaded when your module is required by another application](https://docs.npmjs.com/creating-node-js-modules#create-the-file-that-will-be-loaded-when-your-module-is-required-by-another-application)
- - if `main` isn’t set, a default name of `index.js` will be used
- - if `main` isn't set, it is recommended (but not required) to create an empty index.js file with the contents `//no-op` (short for no-operation), as seen in this [example plugin](https://github.com/gatsbyjs/gatsby/tree/817a6c14543c73ea8f56c9f93d401b03adb44e9d/packages/gatsby-source-wikipedia)
- - `version` is used to manage the cache — if it changes, the cache is cleared
- - if `version` isn’t set, an MD5 hash of the `gatsby-*` file contents is used to invalidate the cache
- - omitting the `version` field is recommended for local plugins
- - `keywords` is used to make your plugin discoverable
- - plugins published on the npm registry should have `gatsby` and `gatsby-plugin` in the `keywords` field to be added to the [Plugin Library](/plugins/)
-- `gatsby-browser.js` — usage details are in the [browser API reference](/docs/reference/config-files/gatsby-browser/)
-- `gatsby-node.js` — usage details are in the [Node API reference](/docs/reference/config-files/gatsby-node/)
-- `gatsby-ssr.js` — usage details are in the [SSR API reference](/docs/reference/config-files/gatsby-ssr/)
diff --git a/docs/docs/gatsby-internals.md b/docs/docs/gatsby-internals.md
deleted file mode 100644
index 8176264c71397..0000000000000
--- a/docs/docs/gatsby-internals.md
+++ /dev/null
@@ -1,147 +0,0 @@
----
-title: Behind the Scenes with Gatsby Internals
----
-
-Curious how Gatsby works under the hood? The pages in this section describe how a Gatsby build works from an internal code/architecture point of view. It should be useful for anyone who needs to work on the internals of Gatsby, or for those who are simply curious how it all works, or perhaps you're a plugin author and need to understand how core works to track down a bug? Come one, come all!
-
-If you're looking for information on how to _use_ Gatsby to write your own site, or create a plugin, check out the rest of the Gatsby docs. This section is quite low level.
-
-These docs aren't supposed to be definitive, or tell you everything there is to know. But as you're exploring the Gatsby codebase, you might find yourself wondering what a concept means, or which part of the codebase implements a particular idea. These docs aim to answer those kinds of questions.
-
-A few more things. These docs are mostly focused on the build lifecycle (`gatsby build`). Operations specific to the develop lifecycle (`gatsby develop`) are mostly ignored. Though this may change in the future. Also, they mostly focus on the happy path, rather than getting bogged down in details of error handling.
-
-The graph below shows roughly how all the sub systems of Gatsby fit together and the input/output artifacts at different parts of the build. To find out how different parts work, click on the nodes in the graph, or use the menu on the left.
-
-> Note: This diagram isn't up to date with the latest version of Gatsby. You can help by making a PR to [update this documentation](https://github.com/gatsbyjs/gatsby/issues/14228)
-
-```dot
-digraph graphname {
-
- node [ style = filled, fillcolor = white ];
-
- ## Legend
-
- subgraph cluster_legend {
- label = "Legend";
- gatsby [ label = "Gatsby", width=1 ];
- redux [ label = "redux namespace", shape = box, fillcolor = skyblue, width=1 ];
- cache [ label = "site/.cache/", shape = cylinder, fillcolor = moccasin, width=1 ];
- public [ label ="site/public/", shape = cylinder, fillcolor = palegreen, width=1 ];
- siteData [ label = "site/external data", shape = cylinder, fillcolor = gray, width=1 ];
-
- siteData -> gatsby [ style = invis ];
- gatsby -> redux [ style = invis ] ;
- redux -> cache [ style = invis ];
- cache -> public [ style = invis ];
- }
-
- ## Source Nodes
-
- dataSource [ label = "data sources. e.g. file, contentful", shape = cylinder, fillcolor = gray ];
- sourceNodes [ label = "source nodes" URL = "/docs/node-creation/" ];
- nodes [ label = "nodes", shape = box, fillcolor = skyblue, URL = "/docs/node-creation/" ];
- nodesTouched [ label = "touchedNodes", shape = box, fillcolor = skyblue, URL = "/docs/node-creation/#freshstale-nodes" ];
- rootNodeMap [ label = "rootNodeMap", shape = box, fillcolor = skyblue, URL = "/docs/node-tracking/" ];
-
- dataSource -> sourceNodes;
- sourceNodes -> nodes;
- sourceNodes -> nodesTouched;
- sourceNodes -> rootNodeMap;
-
- ## Schema
-
- pluginResolvers [ label = "plugin resolvers", shape = cylinder, fillcolor = gray, URL = "/docs/schema-input-gql/#inferring-input-filters-from-plugin-fields" ];
- generateSchema [ label = "generate schema", URL = "/docs/schema-generation/" ];
- schema [ label = "schema\l (inc resolvers)", shape = box, fillcolor = skyblue ];
-
- nodes -> generateSchema;
- nodes -> schema;
- pluginResolvers -> generateSchema;
- rootNodeMap -> generateSchema;
- generateSchema -> schema;
-
- ## Pages
-
- componentFiles [ label = "React components\l (src/template.js)", shape = cylinder, fillcolor = gray ];
- createPages [ label = "site.createPages", URL = "/docs/page-creation/" ];
- pages [ label = "pages", shape = box, fillcolor = skyblue ];
- components [ label = "components", shape = box, fillcolor = skyblue ];
-
- schema -> createPages;
- componentFiles -> createPages;
- createPages -> pages;
- createPages -> components;
-
- ## Query
-
- fragments [ label = "query fragments *.js", shape = cylinder, fillcolor = gray ];
- runQueries [ label = "extract and run queries", URL = "/docs/query-behind-the-scenes/" ];
- componentsWithQueries [ label = "components\l (with queries)", shape = box, fillcolor = skyblue ];
- queryResults [ label = "JSON result\l /public/static/d/dataPath", shape = cylinder, fillcolor = palegreen, URL = "/docs/query-execution/#save-query-results-to-redux-and-disk" ];
- dataPaths [ label = "jsonDataPaths", shape = box, fillcolor = skyblue ];
-
- fragments -> runQueries;
- schema -> runQueries;
- pages -> runQueries;
- components -> runQueries;
- runQueries -> componentsWithQueries;
- runQueries -> queryResults;
- runQueries -> dataPaths;
-
- ## Write Pages
-
- writePages [ label = "writePages", URL = "/docs/write-pages/" ];
- dataJson [ label = "data.json", shape = cylinder, fillcolor = moccasin ];
- asyncRequires [ label = "async-requires.js", shape = cylinder, fillcolor = moccasin ];
- syncRequires [ label = "sync-requires.js", shape = cylinder, fillcolor = moccasin ];
- pagesJson [ label = "pages.json", shape = cylinder, fillcolor = moccasin ];
-
- dataPaths -> writePages;
- components -> writePages;
- pages -> writePages;
- writePages -> dataJson;
- writePages -> asyncRequires;
- writePages -> syncRequires;
- writePages -> pagesJson;
-
- ## App.js
-
- appWebpack [ label = "configure webpack\l (`build-javascript`)", URL = "/docs/production-app/#webpack-config" ];
- productionApp [ label = "production-app.js", shape = cylinder, fillcolor = moccasin, URL = "/docs/production-app/#production-appjs" ];
- buildJavascript [ label = "build-javascript.js", URL = "/docs/production-app/" ];
- componentChunks [ label = "component chunks\l component---src-blog-[hash].js", shape = cylinder, fillcolor = palegreen, URL = "/docs/how-code-splitting-works/" ];
- appChunk [ label = "app-[hash].js", shape = cylinder, fillcolor = palegreen ];
- webpackStats [ label = "webpack.stats.json", shape = cylinder, fillcolor = palegreen, URL = "/docs/how-code-splitting-works/#webpackstatsjson" ];
- chunkMap [ label = "chunk-map.json", shape = cylinder, fillcolor = palegreen, URL = "/docs/how-code-splitting-works/#chunk-mapjson" ];
-
- appWebpack -> buildJavascript;
- asyncRequires -> productionApp;
- dataJson -> productionApp;
- productionApp -> buildJavascript;
- buildJavascript -> componentChunks;
- buildJavascript -> appChunk;
- buildJavascript -> webpackStats;
- buildJavascript -> chunkMap;
-
- queryResults -> componentChunks;
-
- ## Generate html
-
- htmlWebpack [ label = "configure webpack\l (`build-html`)", URL = "/docs/html-generation/#webpack" ];
- staticEntry [ label = "static-entry.js", shape = cylinder, fillcolor = moccasin, URL = "/docs/html-generation/#static-entryjs" ];
- buildHtml [ label = "build-html.js", URL = "/docs/html-generation/" ];
- pageRenderer [ label = "page-renderer.js", shape = cylinder, fillcolor = palegreen ];
- htmlFiles [ label = "html files\l (index.html)", shape = cylinder, fillcolor = palegreen ];
-
- htmlWebpack -> buildHtml;
- syncRequires -> staticEntry;
- dataJson -> staticEntry;
- webpackStats -> staticEntry;
- chunkMap -> staticEntry;
- staticEntry -> buildHtml;
- buildHtml -> pageRenderer;
- pages -> buildHtml;
- pageRenderer -> buildHtml;
- buildHtml -> htmlFiles;
-}
-```
diff --git a/docs/docs/gatsby-repl.md b/docs/docs/gatsby-repl.md
deleted file mode 100644
index b0913f379053b..0000000000000
--- a/docs/docs/gatsby-repl.md
+++ /dev/null
@@ -1,205 +0,0 @@
----
-title: Gatsby REPL
----
-
-The Gatsby REPL ("read-eval-print loop") is available via the Gatsby CLI by running the command `gatsby repl`. This gives you access to an interactive REPL shell within the context of your Gatsby environment. It can be used to retrieve general data and programmatically interact with it. If you have an idea for a new command, feel free to submit a PR for it!
-
-This doc will give a brief description of each REPL command, expected output, and an example of what you can do with the command to digest the data. Examples are using the [Gatsby Starter Blog](/starters/gatsbyjs/gatsby-starter-blog/) as a demo environment, since it is currently the highest rated starter, and provides standard output for most of these commands.
-
-To get started, in your terminal, after running the initial site setup steps [here](/docs/quick-start), run the command `gatsby repl` to enter the interactive shell. If you are writing out a function, you can write that over multiple lines, as long as you do not use a semicolon or close a parenthesis or brace prematurely. This is helpful for running GraphQL queries and callback functions.
-
-## REPL Commands
-
-### `babelrc`
-
-Returns an object with the global `babelrc` settings.
-
-Usage: `babelrc`
-
-Example:
-
-```js
-// Command:
-gatsby > babelrc
-// Returns:
-{ stages:
- { develop: { plugins: [], presets: [], options: [Object] },
- 'develop-html': { plugins: [], presets: [], options: [Object] },
- 'build-html': { plugins: [], presets: [], options: [Object] },
- 'build-javascript': { plugins: [], presets: [], options: [Object] } } }
-```
-
-### `components`
-
-Returns a Map object with all of the components in your Gatsby environment (see [Mozilla Map](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map) docs for more information on Map objects and how to use them). Properties that get returned: `name`, `componentPath`, `query`, `pages`, and `isInBootstrap:`.
-
-Usage: `components`
-
-Example:
-
-```js
-// Command:
-gatsby > for( var [key, value] of components ) { console.log(key + ' = ' + value.pages); }
-// Returns: a list of components and the pages they are used on...
-.../my-blog-starter/src/templates/blog-post.js = /hi-folks/,/my-second-post/,/hello-world/
-.../my-blog-starter/src/pages/404.js = /404/,/404.html
-.../my-blog-starter/src/pages/index.js = /
-.../my-blog-starter/.cache/dev-404-page.js = /dev-404-page/
-```
-
-### `getNode()`
-
-Get a single node by its ID, typically a string.
-
-Usage: `getNode()`
-
-Example:
-
-```js
-// Command:
-gatsby > getNode('SitePage /404.html')
-// Returns:
-{ internalComponentName: 'Component404Html',
- path: '/404.html',
- ...
- id: 'SitePage /404.html',
- ...
- internal:
- { type: 'SitePage',
- contentDigest: '3688d3ee613222ebfe3f44bbdaeb8ca0',
- description: 'f795702c-a3b8-5a88-88ee-5d06019d44fa',
- owner: 'internal-data-bridge' } }
-```
-
-### `getNodes()`
-
-Returns an array of objects (the nodes).
-
-Usage: `getNodes()`
-
-Examples:
-
-```js
-// Command:
-gatsby > getNodes().map(node=>node.internal.type)
-// Returns:
-[ 'SitePage',
- 'SitePlugin',
- 'SitePlugin',
- 'SitePlugin',
- 'SitePlugin',...] // An array of each node's internal type.
-
-// Command:
-gatsby > getNodes().filter(node=> {if('MarkdownRemark' == node.internal.type) return node}).map(node=> node.frontmatter.title)
-// Returns:
-[ 'Hello World', 'My Second Post!', 'New Beginnings' ] // First returns an array of just nodes with a MarkdownRemark type, then creates an array of titles (blog posts).
-```
-
-### `nodes`
-
-`nodes` is like `getNodes()`, but returns an **indexed** array of objects (the nodes). You can also pass in the index of the node you want, and that will return an array with a single node object.
-
-Usage: `nodes` returns the array, or `nodes[]` returns an array with a node object.
-
-Examples:
-
-```js
-// Command:
-gatsby > nodes.length
-// Returns:
-48 // The length of the nodes array.
-
-// Command
-gatsby > nodes[47]
-// Returns:
-[ 47,
- { internalComponentName: 'Component404Html',
- path: '/404.html',
- ...
- componentPath: '.../my-blog-starter/src/pages/404.js',
- id: 'SitePage /404.html',
- ...
- internal:
- { type: 'SitePage',
- contentDigest: '1047b0e301924ae75175482834ef7b1a',
- description: 'f795702c-a3b8-5a88-88ee-5d06019d44fa',
- owner: 'internal-data-bridge' } } ]
-```
-
-### `pages`
-
-Returns an indexed array of arrays. Each array contains a key which is the slug, and a value which is the page node object.
-
-Usages: `pages` or `pages[]`
-
-Example:
-
-```js
-// Command:
-gatsby > pages[0]
-// Returns:
-[ '/hi-folks/',
- { internalComponentName: 'ComponentHiFolks',
- path: '/hi-folks/',
- ...
- componentPath:
- '.../my-blog-starter/src/templates/blog-post.js' } ]
-```
-
-### `schema`
-
-Returns the GraphQL schema of your Gatsby environment as an object.
-
-Usages: `schema` or `schema[]`
-
-Example:
-
-```js
-// Command:
-gatsby > schema._implementations
-// Result:
-[Object: null prototype] {
- Node:
- [ File,
- MarkdownRemark,
- ImageSharp,
- SitePage,
- SitePlugin,
- Site,
- Directory ] } // Returns the property value of implementations.
-```
-
-### `siteConfig`
-
-Returns the settings you would find in the `gatsby-config.js` file of your site as an object.
-
-Usages: `siteConfig` or `siteConfig[]`
-
-Example:
-
-```js
-// Command:
-gatsby > siteConfig.siteMetadata
-// Returns:
-{ title: 'Gatsby Starter Blog',
- author: 'Kyle Mathews',
- description: 'A starter blog demonstrating what Gatsby can do.',
- siteUrl: 'https://gatsby-starter-blog-demo.netlify.app/',
- social: { twitter: 'kylemathews' } } // returns just the siteMetadata value of the config.
-```
-
-### `staticQueries`
-
-Returns a Map object with all of the static queries in your Gatsby environment. Properties that get returned: `name`, `componentPath`, `id`, `query`, and `hash`.
-
-Usage: `staticQueries`
-
-Example:
-
-```js
-// Command:
-gatsby > for( var [key, value] of staticQueries ) { console.log(key + ' = ' + value.componentPath); }
-// Returns:
-sq--src-components-seo-js = .../my-blog-starter/src/components/seo.js
-sq--src-components-bio-js = .../my-blog-starter/src/components/bio.js
-```
diff --git a/docs/docs/glossary/decoupled-drupal.md b/docs/docs/glossary/decoupled-drupal.md
deleted file mode 100644
index c7a923a0709ba..0000000000000
--- a/docs/docs/glossary/decoupled-drupal.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: What Is Headless or Decoupled Drupal?
-disableTableOfContents: true
----
-
-_Decoupled Drupal_ is the practice of using Drupal as a [headless CMS](/docs/how-to/sourcing-data/headless-cms/) for your [Jamstack](/docs/glossary/jamstack/) site. Decoupled Drupal separates the content layer from the presentation layer, so that you can use Drupal, as the content management systems, with whatever frontend you choose.
-
-In a tightly coupled Drupal architecture, themes control your site's appearance using PHP and bit of Drupal DSL. A theme is a collection of HTML-based template files, each of which manages the layout for a particular Drupal node or content type.
-
-When a visitor requests a URL, Drupal retrieves the requested content from the database and merges it with the appropriate template to create an HTML response. The downside of such an architecture is that your site's content is only available as HTML. HTML limits where and how your content can be used.
-
-In a decoupled architecture, Drupal's only responsibility is content. Rather than returning HTML documents, Drupal returns JSON from its [REST](https://www.drupal.org/docs/8/api/restful-web-services-api/restful-web-services-api-overview) or [JSON:API](https://www.drupal.org/docs/8/modules/jsonapi/api-overview) interfaces. Or you can use [GraphQL](/docs/glossary/graphql/) by installing the [GraphQL module](https://www.drupal.org/docs/8/modules/graphql).
-
-A decoupled Drupal architecture offers two key advantages over a tightly coupled one.
-
-- **You can use one content management system to serve multiple frontends** — for example, your Gatsby site, your mobile application, and your smart TV application.
-- **You can develop, change, and upgrade the frontend and backend independently of each other.** Upgrading Drupal doesn't require you to modify your site's appearance.
-
-To use Drupal as a content source for Gatsby, add the [`gatsby-source-drupal`](/plugins/gatsby-source-drupal/) plugin to your project. As with Gatsby itself, you install the `gatsby-source-drupal` plugin using [npm](/docs/glossary/#npm).
-
-```shell
-npm install gatsby-source-drupal
-```
-
-A decoupled Drupal architecture lets you use the full power of Drupal's content management tools while gaining the performance advantages of a static Gatsby site.
-
-## Learn more about decoupled Drupal
-
-- Watch [Kyle Mathews’ presentation on Gatsby + Drupal](https://2017.badcamp.net/session/coding-development/beginner/headless-drupal-building-blazing-fast-websites-reactgatsbyjs)
-- Documentation for the [GraphQL Drupal module](https://drupal-graphql.gitbook.io/graphql/)
-- [Sourcing from Drupal](/docs/how-to/sourcing-data/sourcing-from-drupal/) in the Gatsby docs
diff --git a/docs/docs/glossary/graphql.md b/docs/docs/glossary/graphql.md
deleted file mode 100644
index 7840423bce35f..0000000000000
--- a/docs/docs/glossary/graphql.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: GraphQL
-disableTableOfContents: true
----
-
-## What is GraphQL?
-
-GraphQL is a query language for requesting information from an [API](/docs/glossary#api), and a protocol for servers that support it. GraphQL is one of the ways that you can import data into your Gatsby components.
-
-Facebook created GraphQL in 2012 when it realized that it needed an API capable of supporting both web-based and native mobile applications. Facebook released GraphQL with an open source license in 2015.
-
-More traditional APIs use a separate endpoint for each piece or type of data you'd like to request. For example, a newspaper API might contain:
-
-- an `/articles/` endpoint that returns a specific news story;
-- a `/reporters/` endpoint that returns information about a particular reporter.
-
-A single news article page might require two separate network requests: one to retrieve the story data, and another for the reporter's contact details. What's more, the `/reporters` endpoint may return more data than you want to display; it might return their biography and social media accounts, when their name, email, and photo are all that you need for the page.
-
-A GraphQL API, on the other hand, has a single endpoint. To retrieve data, you send one request string that uses a GraphQL-specific syntax. GraphQL executes the functions necessary to retrieve the data that you've requested, and returns a single JSON response.
-
-A request for an article and its reporter might look like the example that follows.
-
-```graphql
-{
- article(id: '7fdc2787469b') {
- title
- body
- reporter(id: '64669b3f') {
- name
- email
- photo
- }
- }
-}
-```
-
-And its response contains only what you've requested.
-
-```json
-{
- "data": {
- "article": {
- "title": "Gatsby promotes GraphQL adoption",
- "body": "...",
- "reporter": {
- "name": "Jane Gatsby",
- "email": "janereports@example.com",
- "photo": "images/reporters/janegatsby.jpg"
- }
- }
- }
-}
-```
-
-You do not have to use GraphQL with Gatsby, however GraphQL offers a few advantages over other methods of importing data.
-
-- You can retrieve only the data that you need for a view.
-- You can add new data types and capabilities without needing to create a new endpoint.
-- You can store content in whatever way makes sense for your site, whether that's in a database, a third-party headless CMS, or Markdown-formatted text files.
-
-## Learn more
-
-- [GraphQL & Gatsby](/docs/graphql/)
-
-- [Why Gatsby Uses GraphQL](/docs/why-gatsby-uses-graphql/)
-
-- [GraphQL](https://graphql.org) official site
-
-- [How to GraphQL](https://www.howtographql.com/)
diff --git a/docs/docs/how-plugins-apis-are-run.md b/docs/docs/how-plugins-apis-are-run.md
deleted file mode 100644
index 2437f8f6ed402..0000000000000
--- a/docs/docs/how-plugins-apis-are-run.md
+++ /dev/null
@@ -1,123 +0,0 @@
----
-title: How APIs/Plugins Are Run
----
-
-> This documentation isn't up to date with the latest version of Gatsby.
->
-> - mention how multiple configurations are merged
-> - the node creation flow in the diagram is no longer correct
-> - `CREATE_NODE` and `onCreateNode` are handled differently than described
->
-> You can help by making a PR to [update this documentation](https://github.com/gatsbyjs/gatsby/issues/14228).
-
-For most sites, plugins take up the majority of the build time. So what's really happening when APIs are called?
-
-_Note: this section only explains how `gatsby-node` plugins are run. Not browser or SSR plugins_
-
-## Early in the build
-
-Early in the bootstrap phase, you [load all the configured plugins](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/bootstrap/load-plugins/index.js#L40) (and internal plugins) for the site. These are saved into Redux under the `flattenedPlugins` namespace. Each plugin in Redux contains the following fields:
-
-- **resolve**: absolute path to the plugin's directory
-- **id**: String concatenation of 'Plugin ' and the name of the plugin. E.g. `Plugin query-runner`
-- **name**: The name of the plugin. E.g. `query-runner`
-- **version**: The version as per the package.json. Or if it is a site plugin, one is generated from the file's hash
-- **pluginOptions**: Plugin options as specified in [gatsby-config.js](/docs/reference/config-files/gatsby-config/)
-- **nodeAPIs**: A list of node APIs that this plugin implements. E.g. `[ 'sourceNodes', ...]`
-- **browserAPIs**: List of browser APIs that this plugin implements
-- **ssrAPIs**: List of SSR APIs that this plugin implements
-
-In addition, you also create a lookup from API to the plugins that implement it and save this to Redux as `api-to-plugins`. This is implemented in [load-plugins/validate.js](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/bootstrap/load-plugins/validate.js#L106)
-
-## apiRunInstance
-
-Some API calls can take a while to finish. So every time an API is run, you create an object called [apiRunInstance](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/utils/api-runner-node.js#L179) to track it. It contains the following notable fields:
-
-- **id**: Unique identifier generated based on type of API
-- **api**: The API you're running. E.g. `onCreateNode`
-- **args**: Any arguments passed to `api-runner-node`. E.g. a node object
-- **pluginSource**: optional name of the plugin that initiated the original call
-- **resolve**: promise resolve callback to be called when the API has finished running
-- **startTime**: time that the API run was started
-- **span**: opentracing span for tracing builds
-- **traceId**: optional args.traceId provided if API will result in further API calls ([see below](#using-traceid-to-await-downstream-api-calls))
-
-Immediately place this object into an `apisRunningById` Map, where you track its execution.
-
-## Running each plugin
-
-Next, filter all `flattenedPlugins` down to those that implement the API you're trying to run. For each plugin, you require its `gatsby-node.js` and call its exported API function. E.g. if API was `sourceNodes`, it would result in a call to `gatsbyNode['sourceNodes'](...apiCallargs)`.
-
-## Injected arguments
-
-API implementations are passed a variety of useful [actions](/docs/reference/config-files/actions/) and other interesting functions/objects. These arguments are [created](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/utils/api-runner-node.js#L94) each time a plugin is run for an API, which allows us to rebind actions with default information.
-
-All actions take 3 arguments:
-
-1. The core information required by the action. E.g. for [createNode](/docs/reference/config-files/actions/#createNode), you must pass a node
-2. The plugin that is calling this action. E.g. `createNode` uses this to assign the owner of the new node
-3. An object with misc action options:
- - `traceId`: [See below](#using-traceid-to-await-downstream-api-calls)
- - `parentSpan`: opentracing span (see [tracing docs](/docs/performance-tracing/))
-
-Passing the plugin and action options on every single action call would be extremely painful for plugin/site authors. Since you know the plugin, `traceId` and `parentSpan` when you're running your API, you can rebind injected actions so these arguments are already provided. This is done in the [doubleBind](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/utils/api-runner-node.js#L14) step.
-
-## Waiting for all plugins to run
-
-Each plugin is run inside a [map-series](https://www.npmjs.com/package/map-series) promise, which allows them to be executed concurrently. Once all plugins have finished running, you remove them from [`apisRunningById`](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/utils/api-runner-node.js#L246) and fire a `API_RUNNING_QUEUE_EMPTY` event. This in turn, results in any dirty pages being recreated, as well as their queries. Finally, the results are returned.
-
-## Using `traceId` to await downstream API calls
-
-The majority of API calls result in one or more implementing plugins being called. You then wait for them all to complete, and return. But some plugins (e.g. [sourceNodes](/docs/reference/config-files/gatsby-node/#sourceNodes)) result in calls to actions that themselves call APIs. You need some way of tracing whether an API call originated from another API call, so that you can wait on all child calls to complete. The mechanism for this is the `traceId`.
-
-```dot
-digraph {
- node [ shape="box" ];
-
- "initialCall" [ label="apiRunner(`sourceNodes`, {\l traceId: `initial-sourceNodes`,\l waitForCascadingActions: true,\l parentSpan: parentSpan\l})\l " ];
- "apiRunner1" [ label="api-runner-node.js" ];
- "sourceNodes" [ label="plugin.SourceNodes()" ];
- "createNode" [ label="createNode(node)" ];
- "apisRunning" [ label="apisRunningByTraceId[traceId]" ];
- "createNodeReducer" [ label="CREATE_NODE reducer" ];
- "CREATE_NODE" [ label="CREATE_NODE event" ];
- "pluginRunner" [ label="plugin-runner.js" ];
- "onCreateNode" [ label="plugin.onCreateNode()" ];
- "apiRunnerOnCreateNode" [ label="apiRunner(`onCreateNode`, {\l node,\l traceId: action.traceId\l})\l "; ];
- "apiRunner2" [ label="api-runner-node.js" ];
-
- "initialCall" -> "apiRunner1";
- "apiRunner1" -> "apisRunning" [ label="set to 1" ];
- "apiRunner1" -> "sourceNodes" [ label="call" ];
- "sourceNodes" -> "createNode" [ label="call (traceID passed via doubleBind)" ];
- "createNode" -> "createNodeReducer" [ label="triggers (action has traceId)" ];
- "createNodeReducer" -> "CREATE_NODE" [ label="emits (event has traceId)" ];
- "CREATE_NODE" -> "pluginRunner" [ label="handled by (event has traceId)" ];
- "pluginRunner" -> "apiRunnerOnCreateNode";
- "apiRunnerOnCreateNode" -> "apiRunner2";
- "apiRunner2" -> "onCreateNode" [ label="call" ];
- "apiRunner2" -> "apisRunning" [ label="increment" ];
-}
-```
-
-1. The `traceId` is passed as an argument to the original API runner. E.g
-
- ```javascript
- apiRunner(`sourceNodes`, {
- traceId: `initial-sourceNodes`,
- waitForCascadingActions: true,
- parentSpan: parentSpan,
- })
- ```
-
-2. You keep track of the number of API calls with this `traceId` in the [`apisRunningByTraceId`](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/utils/api-runner-node.js#L139) Map. On this first invocation, it will be set to `1`.
-
-3. Using the action rebinding mentioned [above](#injected-arguments), the `traceId` is passed through to all action calls via the `actionOptions` object.
-
-4. After reducing the Action, a global event is [emitted](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/redux/index.js#L93) which includes the action information
-
-5. For the `CREATE_NODE` and `CREATE_PAGE` events, you need to call the `onCreateNode` and `onCreatePage` APIs respectively. The [plugin-runner](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/redux/plugin-runner.js) takes care of this. It also passes on the `traceId` from the Action back into the API call.
-
-6. You're back in `api-runner-node.js` and can tie this new API call back to its original. So you increment the value of [`apisRunningByTraceId`](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/utils/api-runner-node.js#L218) for this `traceId`.
-
-7. Now, whenever an API finishes running (when all its implementing plugins have finished), you decrement `apisRunningByTraceId[traceId]`. If the original API call included the `waitForCascadingActions` option, then you wait until `apisRunningByTraceId[traceId]` == 0 before resolving.
diff --git a/docs/docs/how-to/routing/mdx-plugins.md b/docs/docs/how-to/routing/mdx-plugins.md
deleted file mode 100644
index 373a3cb76649e..0000000000000
--- a/docs/docs/how-to/routing/mdx-plugins.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: MDX Plugins
----
-
-## Gatsby remark plugins
-
-`gatsby-plugin-mdx` is compatible with all of the [gatsby-remark
-plugins](/plugins/gatsby-remark-images/?=gatsby-remark),
-including
-[`gatsby-remark-images`](/plugins/gatsby-remark-images/?=gatsby-remark).
-
-To enable `gatsby-remark-images`, you first need to install the relevant
-image plugins:
-
-```shell
-yarn add gatsby-plugin-sharp gatsby-remark-images
-```
-
-If you don't have `gatsby-source-filesystem` installed, also install that.
-
-Then configure the plugins. `gatsby-source-filesystem` needs to be
-pointed at wherever you have your images on disk, `gatsby-remark-images`
-needs to be both a sub-plugin of `gatsby-plugin-mdx`and a string entry in
-the plugins array, and `gatsby-plugin-sharp` can be included on its own.
-
-```javascript:title=gatsby-config.js
-module.exports = {
- plugins: [
- `gatsby-plugin-sharp`,
- `gatsby-remark-images`,
- {
- resolve: `gatsby-plugin-mdx`,
- options: {
- gatsbyRemarkPlugins: [
- {
- resolve: `gatsby-remark-images`,
- options: {
- maxWidth: 1035,
- sizeByPixelDensity: true,
- },
- },
- ],
- },
- },
- {
- resolve: `gatsby-source-filesystem`,
- options: {
- path: `${__dirname}/src/pages`,
- },
- },
- ],
-}
-```
-
-Then, any image in your MDX file will be automatically handled
-by Gatsby image processing.
-
-```markdown
-
-```
-
-By default, the text `my image` will be used as the alt attribute of the
-generated `img` tag. If an empty alt attribute like `alt=""` is wished,
-a reserved keyword `GATSBY_EMPTY_ALT` can be used.
-
-```markdown
-
-```
-
-## Remark plugins
-
-You can use [remark plugins](https://github.com/remarkjs/remark/blob/master/doc/plugins.md)
-directly if there are transformations you'd like to make on your
-MDX documents. This can do anything from adding emoji support to
-enforcing a particular title capitalization format.
-
-```javascript:title=gatsby-config.js
-const capitalize = require(`remark-capitalize`)
-const emoji = require(`remark-emoji`)
-
-module.exports = {
- plugins: [
- {
- resolve: `gatsby-plugin-mdx`,
- options: {
- remarkPlugins: [capitalize, emoji],
- },
- },
- ],
-}
-```
diff --git a/docs/docs/loading-plugins-from-your-local-plugins-folder.md b/docs/docs/loading-plugins-from-your-local-plugins-folder.md
deleted file mode 100644
index 1468aa050d8d3..0000000000000
--- a/docs/docs/loading-plugins-from-your-local-plugins-folder.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Loading Plugins from Your Local Plugins Folder
----
-
-Gatsby can load plugins from your website's local plugins folder, which is a folder named `plugins` in the website's root directory.
-
-Consider this example project structure which includes a local plugin called `gatsby-local-plugin`:
-
-```text
-/my-gatsby-site
-└── /src
- └── /pages
- └── /components
-
-└── /plugins
- └── /gatsby-local-plugin
- └── /package.json
- └── /gatsby-node.js
-
-└── gatsby-config.js
-└── gatsby-node.js
-└── package.json
-```
-
-Like the name of the plugins folder implies, you can include multiple plugins in your local plugin folder.
-
-Including a local plugin in your plugins folder also requires a configuration step (similar to a third-party plugin you've installed in your `node_modules` folder by running `npm install`); just as plugins installed from npm need to be included in your `gatsby-config`, you need to add the name of your local plugin to the plugins array as well:
-
-```javascript:title=gatsby-config.js
-module.exports = {
- plugins: [
- `gatsby-third-party-plugin`,
- `gatsby-local-plugin`, // highlight-line
- ],
-}
-```
-
-## Verifying your plugin is loading
-
-To verify that your plugin is available for use in your Gatsby site, you can add a small snippet of code to a `gatsby-node.js` file (you may need to add the `gatsby-node.js` file if there isn't one already) in the root of your plugin:
-
-```javascript:title=plugins/gatsby-local-plugin/gatsby-node.js
-exports.onPreInit = () => {
- console.log("Testing...")
-}
-```
-
-_The [`onPreInit` API](/docs/reference/config-files/gatsby-node/#onPreInit) is the first Node API called by Gatsby right after plugins are loaded._
-
-Then, when running your site in develop or build mode, you should see "Testing..." logged in your terminal:
-
-```shell
-success open and validate gatsby-configs - 0.051s
-success load plugins - 1.047s
-Testing... // highlight-line
-success onPreInit - 0.023s
-...
-```
-
-## Loading local plugins from _outside_ the plugins folder
-
-If you want to reference a plugin that is not in the plugins folder, there are several options that are described in more detail in the [Creating a Local Plugin guide](/docs/creating-a-local-plugin/).
diff --git a/docs/docs/node-tracking.md b/docs/docs/node-tracking.md
deleted file mode 100644
index 67c5c15a3bd3b..0000000000000
--- a/docs/docs/node-tracking.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Node Tracking
----
-
-## Track Nodes
-
-You may see calls to `trackInlineObjectsInRootNode()` and `findRootNodeAncestor()` in some parts of the code. These are both defined in `schema/node-model.js`. Node tracking is the tracking of relationships between a node's object values (not children), and the node's ID. E.g. Take, the following node:
-
-```javascript
-let nodeA = {
- id: `id2`,
- internal: {
- type: `footype`,
- },
- foo: {
- myfile: "blog/my-blog.md",
- b: 2,
- },
- bar: 7,
- parent: `id1`,
- baz: [{ x: 8 }, 9],
-}
-```
-
-Its sub objects are `foo` (value = `{ myfile: "blog/my-blog.md", b: 2}`), and those in the `baz` array (`{ x: 8 }`). Node tracking will track those back to the top level node's ID (`id2` in this case). The [`trackInlineObjectsinRootNode()`](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/node-model.js#L410) function takes care of this and records those relationships in the [rootNodeMap](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/node-model.js#L69) WeakMap. E.g. after calling `trackInlineObjectsInRootNode(nodeA)`, `rootNodeMap` would contain the following records:
-
-```javascript
-// rootNodeMap:
-{
- { blog: "blog/my-blog.md", b: 2 } => "id2", // from `foo` field
- { x: 8 } => "id2", // from `baz` array
- { // top level object is tracked too
- id: `id2`,
- internal: { // internal is not mapped
- type: `footype`
- },
- foo: {
- blog: "blog/my-blog.md",
- b: 2
- },
- bar: 7,
- parent: `id1`,
- baz: [ { x: 8 }, 9 ]
- } => "id2"
-}
-```
-
-## Find Root Nodes
-
-To access this information, `schema/node-model.js` provides the [findRootNodeAncestor()](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/node-model.js#L403) function. It takes an object, and looks up its parent's nodeID in `rootNodeMap`. It then finds the actual node in Redux. It then gets that node's `parent` ID, and gets the parent node from Redux. And continues in this way until the root node is found.
-
-In the above example, `nodeA` has parent `id1`. So `findRootNodeAncestor({ blog: "blog/my-blog.md", b: 2 })` would return the node for `id1` (the parent).
-
-## Why/Where?
-
-Where is node-tracking used? First up, nodes are tracked in 2 places. Firstly, in [createNode](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/redux/actions/public.js#L694), every time a node is created, we link all its sub objects to the new NodeID. Nodes are also tracked whenever they are resolved in [run-sift](/docs/schema-sift/#3-resolve-inner-query-fields-on-all-nodes). This is necessary because [custom plugin fields](/docs/schema-input-gql/#inferring-input-filters-from-plugin-fields/) might return new objects that weren't created when the node was initially made.
-
-Now, where do we use this information? In 2 places.
-
-1. In the `File` type resolver. It is used to look up the node's root, which should be of type `File`. We can then use that root node's base directory attribute to create the full path of the resolved field's value, and therefore find the actual `File` node that the string value is describing. See [File GqlType inference](/docs/schema-gql-type/#file-types) for more info.
-2. To recursively look up node descriptions in [type-conflict-reporter.ts](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/infer/type-conflict-reporter.ts)
diff --git a/docs/docs/optimizing-site-performance-with-guessjs.md b/docs/docs/optimizing-site-performance-with-guessjs.md
deleted file mode 100644
index c3a14c8d9f938..0000000000000
--- a/docs/docs/optimizing-site-performance-with-guessjs.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Optimizing Site Performance with Guess.js
----
-
-Preloading resources is a great way to improve application performance. However, preloading everything on a page can waste bandwidth. This is especially true for mobile phone users who may have limited data and bandwidth. So how do you know which resources to preload? Is it just a guessing game? Not anymore.
-
-## Introducing Guess.js
-
-By leveraging Google Analytics data and machine learning, [Guess.js](https://github.com/guess-js/guess) is able to determine which pages a user is most likely to navigate to from the current page and only preload those resources. Thus, there are fewer network requests which improves performance on slower networks.
-
-## How does it work?
-
-Guess.js will download a file from Google Analytics during the production build. This file is then used to construct the model for predictive analytics.
-
-## Guess.js and Gatsby
-
-See the [Gatsby Guess.js Plugin](/plugins/gatsby-plugin-guess-js) for more information on integrating Guess.js with Gatsby.
-
-### References:
-
-- [Introducing Guess.js](https://blog.mgechev.com/2018/05/09/introducing-guess-js-data-driven-user-experiences-web/)
-- [Gatsby Plugin Guess.js](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-plugin-guess-js)
-- [Cutting Edge Static Sites](https://www.contentful.com/blog/2018/06/13/journey-cutting-edge-static-sites-gatsbyjs-v2/)
diff --git a/docs/docs/page-creation.md b/docs/docs/page-creation.md
deleted file mode 100644
index bacfeb8c1bda9..0000000000000
--- a/docs/docs/page-creation.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Page Creation
----
-
-A page is created by calling the [createPage](/docs/reference/config-files/actions/#createPage) action. There are three main side effects that occur when a page is created.
-
-1. The `pages` Redux namespace is updated
-2. The `components` Redux namespace is updated
-3. `onCreatePage` API is executed
-
-## Update pages Redux namespace
-
-The `pages` Redux namespace is a map of page `path` to page object. The [pages reducer](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/redux/reducers/pages.ts) takes care of updating this on a `CREATE_PAGE` action. It also creates a [Foreign Key Reference](/docs/schema-gql-type/#foreign-key-reference-___node) to the plugin that created the page by adding a `pluginCreator___NODE` field.
-
-## Update components Redux namespace
-
-The `components` Redux namespace is a map of [componentPath](/docs/behind-the-scenes-terminology/#component) (file with React component) to the Component object. A Component object is the Page object but with an empty query string (that will be set during [Query Extraction](/docs/query-extraction/#store-queries-in-redux)).
-
-## onCreatePage API
-
-Every time a page is created, plugins have the opportunity to handle its [onCreatePage](/docs/reference/config-files/gatsby-node/#onCreatePage) event. This is used for things like creating `SitePage` nodes in [Internal Data Bridge](/docs/internal-data-bridge/).
diff --git a/docs/docs/page-node-dependencies.md b/docs/docs/page-node-dependencies.md
deleted file mode 100644
index bfb2a01e522e0..0000000000000
--- a/docs/docs/page-node-dependencies.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: Page -> Node Dependency Tracking
----
-
-Gatsby keeps a record of used nodes for each query result. This makes it possible to cache and reuse results from previous runs if used nodes didn't change and, conversely, is used to determine which query results are stale and need to be rerun.
-
-## How dependencies are recorded
-
-### `CREATE_COMPONENT_DEPENDENCY` action and `createPageAction` action creator
-
-The internal `CREATE_COMPONENT_DEPENDENCY` action handles the recording of Page -> Node dependencies. It takes the `path` (page path for page queries or internal id for static queries), and either a `nodeId`, or `connection`.
-
-Passing `nodeId` tells Gatsby that the page depends specifically on this node. So, if the node is changed, then the page's query needs to be re-executed.
-
-`connection` is a Type string. E.g. `MarkdownRemark`, or `File`. Calling `createPageDependency` with a `path` and a `connection` tells Gatsby that this page depends on all nodes of this type. Therefore if any node of this type changes (e.g. a change to a markdown node), then this page must be rebuilt. Using connection fields (e.g. `allMarkdownRemark`) is one of the cases when this variant is used.
-
-`CREATE_COMPONENT_DEPENDENCY` action is conditionally dispatched by the internal `createPageAction` action creator. Action creator checks if we already have given dependencies stored to avoid emitting no-op actions. `createPageAction` is a low level internal API that is then used by higher level APIs.
-
-### Higher level abstractions
-
-#### Node Model
-
-[Node Model](/docs/reference/graphql-data-layer/node-model/) is an API used in GraphQL resolvers to retrieve nodes from the data store. It's used internally in resolvers provided by Gatsby core and it can be used in resolvers provided by plugins via `context.nodeModel`. It calls `createPageAction` under the hood because Node Model is aware of the path of the query as well as the nodes being retrieved.
-
-#### `getNodeAndSavePathDependency` helper
-
-[`getNodeAndSavePathDependency`](/docs/reference/config-files/node-api-helpers/#getNodeAndSavePathDependency) is a convenience wrapper around `getNode` and `createPageDependency`. It is not used internally. It's a legacy API for plugins to record data dependencies and is equivalent to `nodeModel.getNodeById`. The Node Model variant should be used instead as its API is less error-prone. (Node Model is `path` aware and doesn't require you to pass it.)
-
-## How dependencies are stored
-
-Page -> Node dependencies are tracked via the `componentDataDependencies` Redux namespace.
-
-```javascript
-{
- nodes: { ... }, // mapping nodeId -> pages
- connections: { ... } // mapping of type names -> pages
-}
-```
-
-**Nodes** is a map of nodeID to the set of pages that depend on that node. E.g
-
-```javascript
-// state.componentDataDependencies.nodes
-{
- `ID of Some MarkdownRemark node`: [
- `blogs/my-blog1`,
- `blogs/my-blog2`
- ],
- `otherId`: [ `more pages`, ...].
- ...
-}
-```
-
-**Connections** is a map of type name to the set of pages that depend on that type. e.g
-
-```javascript
-// state.componentDataDependencies.connections
-{
- `MarkdownRemark`: [
- `blogs/my-blog1`,
- `blogs/my-blog2`
- ],
- `File`: [ `more pages`, ... ],
- ...
-}
-```
-
-## How dependency information is used
-
-Page -> Node dependencies are used entirely during query execution to figure out which nodes are "dirty" and to figure out which queries don't have any dependencies yet. "Dirty" nodes are used to determine which query results are stale and need to be re-executed. Finding queries without dependencies is used as a heuristic to determine which queries haven't run yet and therefore need to run.
diff --git a/docs/docs/performance.md b/docs/docs/performance.md
deleted file mode 100644
index fb36e0c81377e..0000000000000
--- a/docs/docs/performance.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Performance
----
-
-While performance is already at the heart of Gatsby, it's important to ensure you are doing all you can to make your content available to your users as fast as possible. Not all users are enjoying high speed connections, or browsing from a desktop. It's important to make no assumptions and serve the smallest and fastest site possible, to provide an optimal experience for wherever your users might be coming from. Since Gatsby is already doing a lot of the heavy lifting for you there isn't a lot required out of the box to make your site blazing fast, but by following these guides you can ensure the best possible performance and delivery of your content to your users.
-
-This section will cover some ways you can optimize caching, set up `https` on `localhost` for easier testing of performance features, as well as how to measure the performance of your websites, giving you all the tools you need to maximize site performance. If you would like a more in-depth explanation of why performance matters so much, check out this article by Addy Osmani on the [Cost of JavaScript](https://v8.dev/blog/cost-of-javascript-2019).
-
-May your Lighthouse scores all be in the green. 😀
-
-
diff --git a/docs/docs/preparing-your-environment.md b/docs/docs/preparing-your-environment.md
deleted file mode 100644
index 01a774a6b893f..0000000000000
--- a/docs/docs/preparing-your-environment.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Preparing Your Environment
----
-
-To get started with Gatsby, you'll need to make sure you have the following software tools installed:
-
-1. [Node.js](/docs/tutorial/part-0/#install-nodejs-for-your-appropriate-operating-system)
-2. [npm CLI](/docs/tutorial/part-0/#check-your-nodejs-installation)
-3. [Gatsby CLI](/docs/tutorial/part-0/#using-the-gatsby-cli)
-
-For step-by-step installation instructions and detailed explanations of the required software, head on over to the [Gatsby tutorial](/docs/tutorial/part-0/).
-
-The [quick start](/docs/quick-start/) is also available for intermediate to advanced developers.
-
-> **Note:** If you work for an Enterprise-level company where you are unable to pull from public GitHub repositories, you can [still set up Gatsby](/docs/using-gatsby-professionally/using-gatsby-professionally/setting-up-gatsby-without-gatsby-new/).
-
-
diff --git a/docs/docs/processing-payments-with-square.md b/docs/docs/processing-payments-with-square.md
deleted file mode 100644
index f0967f97acf3c..0000000000000
--- a/docs/docs/processing-payments-with-square.md
+++ /dev/null
@@ -1,198 +0,0 @@
----
-title: Processing Payments with Square
----
-
-Square is a payment service that emphasizes quick, secure payments as well as a user-friendly and affordable point of sale (POS) system. You may have already seen their tiny credit card readers, which are great for mobile businesses like those that sell via food trucks or craft fairs. This guide explains how to begin using Square with your Gatsby site.
-
-## Prerequisites
-
-You'll need to [set up a developer account](https://squareup.com/signup?v=developers) to get started. Create a new application from your developer dashboard. The name of your application cannot include the word "square". Once that's done, you should see your new application on your dashboard. Each application has an application ID and access token associated with it.
-
-## Choosing the right product
-
-Square can handle most of your payment-related needs including accepting payments, managing product catalogs, and managing payroll. Begin by determining which of these products you want to incorporate into your business. This guide focuses on [accepting payments on your website](https://developer.squareup.com/docs/online-payment-options#square-payments-in-your-own-website) but you may wish to use their in-person or in-app options as well.
-
-You've got two options for integrating Square payments: redirecting to a hosted checkout page with the Checkout API _or_ taking payments from your Gatsby site using the `SqPaymentForm` library with the Payments API.
-
-### Redirecting to a hosted checkout page
-
-Redirecting to a Square-hosted page takes some of the pressure off since you don't need to build a checkout page. However, getting that functionality "for free" does come with some restrictions. You will not be able to customize the UI of the page users are sent to once they're ready to check out. Square only recommends this option for situations where accepting payments on your own site isn't feasible.
-
-To use the Square [Checkout API](https://developer.squareup.com/docs/checkout-api-overview), you'll need to send a request that includes the relevant order information. In response, you'll get a URL with the format `https://connect.squareup.com/v2/checkout?c={{CHECKOUT_ID}}&l={{LOCATION_ID}}` which you'll redirect your user to. From there, Square handles the payment form UI and processing.
-
-### Accepting Square payments
-
-Square recommends using the Payments API instead because it offers much greater flexibility. You can customize not only the look and feel of the checkout process but also the checkout process itself, such as customizing the payment methods available.
-
-This process is broken into two steps:
-
-1. Generate a single-use token called a nonce.
-2. Charge whatever payment source the user has provided (this could be a credit card, gift card, etc.) using the nonce.
-
-To add a Square payment form to your Gatsby site, you'll need to load the JavaScript that runs Square's payment form into the `` of your website. You can do this by creating a `