diff --git a/index.js b/index.js
index f3c065ac32..a42b89595e 100644
--- a/index.js
+++ b/index.js
@@ -100,7 +100,7 @@ function initHexo () {
   return new Promise((resolve, reject) => {
     const space = hexo.env.GATSBY_CONTENTFUL_SPACE_ID || process.env.GATSBY_CONTENTFUL_SPACE_ID
     const accessToken = hexo.env.GATSBY_CONTENTFUL_ACCESS_TOKEN || process.env.GATSBY_CONTENTFUL_ACCESS_TOKEN
-    const environment = env !== 'production' ? 'staging' : 'master'
+    const environment = hexo.env.GATSBY_CONTENTFUL_ENVIRONMENT || process.env.GATSBY_CONTENTFUL_ENVIRONMENT || 'master'
 
     if (typeof space === 'undefined' || typeof accessToken === 'undefined') {
       return reject({
@@ -109,7 +109,7 @@ function initHexo () {
     }
 
     return Contentful.createClient({ space, accessToken, environment })
-    .getEntries({ content_type: 'topBanner' })
+    .getEntries({ content_type: 'docsTopBanner' })
     .then(({ items }) => {
       const data = items.reduce((filtered, { sys: { id }, fields }) => {
         if (moment(fields.endDate).isSameOrAfter(moment())) {
diff --git a/source/api/commands/its.md b/source/api/commands/its.md
index 162054244d..aeb2777755 100644
--- a/source/api/commands/its.md
+++ b/source/api/commands/its.md
@@ -152,7 +152,7 @@ cy.wrap(user).its('contacts.work.name').should('eq', 'Kamil') // true
 
 ## Existence
 
-### Wait for some propery to exist on `window`
+### Wait for some property to exist on `window`
 
 ```javascript
 cy.window().its('globalProp').then((globalProp) => {
@@ -160,7 +160,7 @@ cy.window().its('globalProp').then((globalProp) => {
 })
 ```
 
-### Assert that a propery does not exist on `window`
+### Assert that a property does not exist on `window`
 
 ```javascript
 cy.window().its('evilProp').should('not.exist')
diff --git a/source/faq/questions/dashboard-faq.md b/source/faq/questions/dashboard-faq.md
index 95ffaf85ce..085ac933af 100644
--- a/source/faq/questions/dashboard-faq.md
+++ b/source/faq/questions/dashboard-faq.md
@@ -47,7 +47,7 @@ No, although we are looking to build an on-premise version of the Dashboard for
 
 ## {% fa fa-angle-right %} Can I choose not to use the Dashboard?
 
-Of course. The Dashboard Service is a separate service from the Test Runner and will always remain optional. We hope you'll find a tremendous amount of value out of it, but it is not coupled to being able to run your tests.
+Of course. The Dashboard Service is a separate service from the Test Runner and will always remain optional. We hope you'll find a tremendous amount of value in it, but it is not coupled to being able to run your tests.
 
 You can always run your tests in CI using {% url "`cypress run`" command-line#cypress-run %} without the `--record` flag which does not communicate with our external servers and will not record any test results.
 
@@ -72,9 +72,9 @@ These will be added in subsequent releases.
 
 Cypress {% url "test parallelization" parallelization %} is indeed based on specs. For each spec the Test Runner scaffolds the new running context, in a sense isolating each spec file from any previous spec files, and ensuring a clean slate for the next spec. Doing this for each _individual_ test would be very very expensive and would slow down the test runs significantly.
 
-Spec file durations are also more meaningful and consistent than timings of individual tests, we can order specs by the moving average of the previously recorded durations. This would be much less useful when load balancing quickly finishing individual tests.
+Spec file durations are also more meaningful and consistent than timings of individual tests, we can order specs by the moving average of the previously recorded durations. This would be much less useful when load balancing quickly finishes individual tests.
 
-To better load balance the specs, thus you would want more spec files with approximately the same running duration. Otherwise, a single very long running test might limit how fast all your tests finish, and the run completes. Due to starting a new test execution context before each spec file and encoding and uploading video after, making spec files to run shorter than approximately 10 seconds would also be fruitless - because Cypress overhead would eat any time savings.
+Thus, to better load balance the specs, you would want more spec files with approximately the same running duration. Otherwise, a single very long running test might limit how fast all your tests finish, and how fast the run completes. Due to starting a new test execution context before each spec file and encoding and uploading video after, making spec files run shorter than approximately 10 seconds would also be fruitless - because Cypress overhead would eat any time savings.
 
 ## {% fa fa-angle-right %} My CI setup is based on Docker, but is very custom. How can I load balance my test runs?
 
@@ -84,7 +84,7 @@ Even if your CI setup is very different from the {% url "CI examples we have" co
 cypress run --record --parallel --ci-build-id $CI_RUN_ID
 ```
 
-For reference, here are {% url "the variables" https://github.com/cypress-io/cypress/blob/develop/packages/server/lib/util/ci_provider.coffee %} we extract from the popular CI providers, and for most of them there is some variable than is set to the same value across multiple containers running in parallel. If there is NO common variable, try using the commit SHA string. Assuming you do not run the same tests more than once against the same commit, it might just be good enough for the job.
+For reference, here are {% url "the variables" https://github.com/cypress-io/cypress/blob/develop/packages/server/lib/util/ci_provider.coffee %} we extract from the popular CI providers, and for most of them there is some variable that is set to the same value across multiple containers running in parallel. If there is NO common variable, try using the commit SHA string. Assuming you do not run the same tests more than once against the same commit, it might just be good enough for the job.
 
 ## {% fa fa-angle-right %} Can I delete a run from the Dashboard?
 
diff --git a/source/faq/questions/general-questions-faq.md b/source/faq/questions/general-questions-faq.md
index 94f2cbc699..f06c1154b6 100644
--- a/source/faq/questions/general-questions-faq.md
+++ b/source/faq/questions/general-questions-faq.md
@@ -49,7 +49,7 @@ Using {% url "Protractor" http://www.protractortest.org/ %} provides a nice Prom
 
 Cypress replaces Protractor because it does all of these things and much more. One major difference is that Cypress enables you to write your unit tests and integration tests in the same tool, as opposed to splitting up this work across both Karma and Protractor.
 
-Also, Protractor is very much focused on `AngularJS`, whereas Cypress is designed to work with any JavaScript framework. Protractor, because it's based on Selenium, is still pretty slow, and is prohibitive when trying to TDD your application. Cypress, on the other hand, runs at the speed your browser and application are capable of serving and rendering, there is no additional bloat.
+Also, Protractor is very much focused on `AngularJS`, whereas Cypress is designed to work with any JavaScript framework. Protractor, because it's based on Selenium, is still pretty slow, and is prohibitive when trying to TDD your application. Cypress, on the other hand, runs at the speed your browser and application are capable of serving and rendering; there is no additional bloat.
 
 ### Sauce Labs
 
@@ -59,10 +59,10 @@ Sauce Labs also has a `manual testing` mode, where you can remotely control brow
 
 Ultimately Sauce Labs and Cypress offer very different value propositions. Sauce Labs doesn't help you write your tests, it takes your existing tests and runs them across different browsers and aggregates the results for you.
 
-Cypress on the other hand **helps** you write your tests. You would use Cypress every day, building and testing your application, and then use Sauce Labs to ensure your application works on every browser.
+Cypress on the other hand **helps** you write your tests. You can use Cypress every day, building and testing your application, and then use Sauce Labs to ensure your application works on every browser.
 
 {% note info A note about Cypress and Sauce Labs %}
-Cypress' API is written to be completely compatible for integration with Sauce Labs. It is our goal to offer full integration with Sauce Labs in the future, however, complete integration is not yet available.
+Cypress' API is written to be completely compatible for integration with Sauce Labs. It is our goal to offer full integration with Sauce Labs in the future; however, complete integration is not yet available.
 {% endnote %}
 
 ## {% fa fa-angle-right %} Do you support X language or X framework?
@@ -87,7 +87,7 @@ No. But if you're wanting to test parts of your application that are not easily
 
 No. In fact Cypress' architecture is very different from Selenium in a few critical ways:
 
-- Cypress runs in the context of the browser. With Cypress it's easier to inspect what is running in the browser, but harder to talk to the outside world. In Selenium it's the exact opposite. Selenium runs outside of the browser where your application is running. Although Cypress is adding more commands every day that give you access to the outside world - like {% url `cy.request()` request %}, {% url `cy.exec()` exec %}, and {% url `cy.task()` task %}.
+- Cypress runs in the context of the browser. With Cypress it's easier to inspect what is running in the browser, but harder to talk to the outside world. In Selenium it's the exact opposite. Selenium runs outside of the browser where your application is running (though Cypress is adding more commands every day that give you access to the outside world - like {% url `cy.request()` request %}, {% url `cy.exec()` exec %}, and {% url `cy.task()` task %}).
 - With Selenium you get either 100% simulated events (with Selenium RC) or 100% native events (with Selenium WebDriver). With Cypress, you get both. For the most part we use simulated events. However we do use automation APIs for things like Cookies where we extend outside of the JavaScript sandbox and interact with the underlying browser APIs. This gives us flexibility to determine which type of event to use in specific situations. Native event support is on our {% url "roadmap" roadmap %}.
 
 ## {% fa fa-angle-right %} If Cypress runs in the browser, doesn't that mean it's sandboxed?
@@ -98,11 +98,11 @@ But Cypress is actually way beyond just a basic JavaScript application running i
 
 All of these technologies together are coordinated and enable Cypress to work, which extends its capabilities far outside of the browser sandbox. Without these, Cypress would not work at all. For the vast majority of your web development, Cypress will work just fine, and already *does* work.
 
-## {% fa fa-angle-right %} We use WebSockets, will Cypress work with that?
+## {% fa fa-angle-right %} We use WebSockets; will Cypress work with that?
 
 Yes.
 
-## {% fa fa-angle-right %} We have the most complex most outrageous authentication system ever, will Cypress work with that?
+## {% fa fa-angle-right %} We have the most complex most outrageous authentication system ever; will Cypress work with that?
 
 If you're using some complex thumb-print, retinal-scan, time-based, key-changing, microphone, audial, decoding mechanism to log in your users, then no, Cypress won't work with that.  But seriously, Cypress is a *development* tool, which makes it easy to test your web applications. If your application is doing 100x things to make it extremely difficult to access, Cypress won't magically make it any easier.
 
@@ -134,7 +134,7 @@ Cypress does *not* utilize WebDriver for testing, so it does not use or have any
 
 Unit tests are not something we are really trying to solve right now. Most of the `cy` API commands are useless in unit tests. The biggest benefit of writing unit tests in Cypress is that they run in a browser, which has debugger support built in.
 
-We have internally experimented at doing DOM based component unit testing in Cypress - and that has the possibility of being an excellent "sweet spot" for unit tests. You'd get full DOM support, screenshot support, snapshot testing, and you could then use other `cy` commands (if need be). But as I mentioned this isn't something we're actively pushing, it just remains a thing that's possible if we wanted to go down that route.
+We have internally experimented at doing DOM based component unit testing in Cypress - and that has the possibility of being an excellent "sweet spot" for unit tests. You'd get full DOM support, screenshot support, snapshot testing, and you could then use other `cy` commands (if need be). But as I mentioned this isn't something we're actively pushing; it just remains a thing that's possible if we wanted to go down that route.
 
 With that said - we actually believe the best form of testing in Cypress is a combination of a "unit test" mixed with an "e2e test". We don't believe in a "hands off" approach. We want you to modify the state of your application, take shortcuts as much as possible (because you have native access to all objects including your app). In other words, we want you to think in unit tests while you write integration tests.
 
@@ -153,7 +153,7 @@ In addition to the above differences, below are a few rules of thumb to decide w
 
 - If the code you are trying to test is called from other code, use a unit test.
 - If the code is going be called from the external system, like a browser, use an end-to-end test.
-- If a unit test requires a lot of mocking and you have to bring tools like `js-dom`, `enzyme`, or `sinon.js` to simulate a real world environment, you may want to rewrite it as an end-to-end test.
+- If a unit test requires a lot of mocking and you have to bring tools like `jsdom`, `enzyme`, or `sinon.js` to simulate a real world environment, you may want to rewrite it as an end-to-end test.
 - If an end-to-end test does *not* go through the browser and instead calls the code directly, you probably want to rewite it as a unit test
 
 Finally, unit and end-to-end tests are not _that_ different and have common features. Good tests:
diff --git a/source/faq/questions/using-cypress-faq.md b/source/faq/questions/using-cypress-faq.md
index e90d0d54d0..e91c8aff82 100644
--- a/source/faq/questions/using-cypress-faq.md
+++ b/source/faq/questions/using-cypress-faq.md
@@ -322,7 +322,7 @@ You can read more about parallelization {% issue 64 'here' %}.
 
 ## {% fa fa-angle-right %} Is Cypress compatible with Sauce Labs and BrowserStack?
 
-Our goal is to offer full integration with Sauce Labs and BrowserStack in the future, however, complete integration is not yet available.
+Our goal is to offer full integration with Sauce Labs and BrowserStack in the future; however, complete integration is not yet available.
 
 ## {% fa fa-angle-right %} Can I run a single test or group of tests?
 
@@ -404,7 +404,7 @@ Cypress.Cookies.defaults({
 
 You **cannot** currently preserve localStorage across tests and can read more {% issue '461#issuecomment-325402086' 'here' %}.
 
-## {% fa fa-angle-right %} Some of my elements animate in, how do I work around that?
+## {% fa fa-angle-right %} Some of my elements animate in; how do I work around that?
 
 Oftentimes you can usually account for animation by asserting {% url "`.should('be.visible')`" should %} or {% url "another assertion" introduction-to-cypress#Assertions %} on one of the elements you expect to be animated in.
 
@@ -570,7 +570,7 @@ That being said, we use Cypress to test our own Desktop app's front end - by stu
 We see organizations _starting_ with Cypress by placing end-to-end tests in a separate repo. This is a great practice that allows someone on the team to prototype a few tests and evaluate Cypress within minutes. As the time passes and the number of tests grows, we _strongly suggest_ moving end-to-end tests to live right alongside your front end code. This brings many benefits:
 
 - engages developers in writing end-to-end tests sooner
-- keeps tests and the features they tests in sync
+- keeps tests and the features they test in sync
 - tests can be run every time the code changes
 - allows code sharing between the application code and the tests (like selectors)
 
@@ -584,7 +584,7 @@ If a test fails, Cypress takes a screenshot image, but does not print the list o
 
 ## {% fa fa-angle-right %} Can my tests interact with Redux / Vuex data store?
 
-Usually your end-to-end tests interact with the application through public browser APIs: DOM, network, storage, etc. But sometimes you might want to assert the data held inside the application's data store. Cypress makes it simple. Tests run right in the same browser instance and can reach into the application's context using {% url `cy.window` window %}. By conditionally exposing the application reference and data store from the application's code, you can allow the tests to make assertions about the data store, and even drive the application via Redux actions.
+Usually your end-to-end tests interact with the application through public browser APIs: DOM, network, storage, etc. But sometimes you might want to make assertions against the data held inside the application's data store. Cypress makes it simple. Tests run right in the same browser instance and can reach into the application's context using {% url `cy.window` window %}. By conditionally exposing the application reference and data store from the application's code, you can allow the tests to make assertions about the data store, and even drive the application via Redux actions.
 
 - see {% url "Testing Redux Store" https://www.cypress.io/blog/2018/11/14/testing-redux-store/ %} blog post and {% url "Redux Testing" recipes#Blogs %} recipe.
 - see {% url "Testing Vue web applications with Vuex data store & REST back end" https://www.cypress.io/blog/2017/11/28/testing-vue-web-application-with-vuex-data-store-and-rest-backend/ %} blog post and {% url 'Vue + Vuex + REST Testing' recipes#Blogs %} recipe.
diff --git a/source/guides/core-concepts/conditional-testing.md b/source/guides/core-concepts/conditional-testing.md
index 40aefa04e8..fe8d22bc39 100644
--- a/source/guides/core-concepts/conditional-testing.md
+++ b/source/guides/core-concepts/conditional-testing.md
@@ -339,7 +339,7 @@ We will reiterate one more time. Had the `<input>` or the `<textarea>` been rend
 
 Cypress is built around creating **reliable tests**. The secret to writing good tests is to provide as much "state" and "facts" to Cypress and to "guard it" from issuing new commands until your application has reached the desired state it needs to proceed.
 
-Doing conditional testing adds a huge problem - that the test writer themselves are unsure what the given state will be. In those situations, the only reliable way to have accurate tests is to embed this dynamic state in a reliable and consistent way.
+Doing conditional testing adds a huge problem - that the test writers themselves are unsure what the given state will be. In those situations, the only reliable way to have accurate tests is to embed this dynamic state in a reliable and consistent way.
 
 If you are not sure if you have written a potentially flaky test, there is an easy way to figure it out. Repeat the test an excessive number of times, and then repeat by modifying the Developer Tools to throttle the Network and the CPU. This will create different loads that simulate different environments (like CI). If you've written a good test, it will pass or fail 100% of the time.
 
@@ -446,4 +446,4 @@ Even then, not enough, it's possible a `setTimeout` could trigger... 60 minutes.
 
 As you approach infinity your confidence does continue to rise on the chances you could prove the desired state will be reached, but you can never prove it will. Instead you could theoretically be waiting for the heat death of the universe for a condition to come that is only a moment away from happening. There is no way to prove or disprove that it *may* conditionally happen.
 
-You, the test writer must know ahead of time what your application is programmed to do - or have 100% confidence that the state of a mutable object (like the DOM) has stabilized in order to write accurate conditional tests.
+You, the test writer, must know ahead of time what your application is programmed to do - or have 100% confidence that the state of a mutable object (like the DOM) has stabilized in order to write accurate conditional tests.
diff --git a/source/guides/core-concepts/interacting-with-elements.md b/source/guides/core-concepts/interacting-with-elements.md
index 7008b70894..cc464204b4 100644
--- a/source/guides/core-concepts/interacting-with-elements.md
+++ b/source/guides/core-concepts/interacting-with-elements.md
@@ -59,7 +59,7 @@ The following calculations factor in CSS translations and transforms.
 ### Additionally an element is considered hidden if:
 
 - Any of its ancestors **hides overflow**\*
-  - AND that ancestor has `width` or `height` of `0`
+  - AND that ancestor has a `width` or `height` of `0`
   - AND an element between that ancestor and the element is `position: absolute`
 - Any of its ancestors **hides overflow**\*
   - AND that ancestor or an ancestor between it and that ancestor is its offset parent
diff --git a/source/guides/core-concepts/retry-ability.md b/source/guides/core-concepts/retry-ability.md
index 46d27a6213..a68fcb095a 100644
--- a/source/guides/core-concepts/retry-ability.md
+++ b/source/guides/core-concepts/retry-ability.md
@@ -49,7 +49,7 @@ Because nothing is synchronous in modern web applications, Cypress can't query a
 Thus the Cypress {% url `cy.get` get %} command has to be smarter and expect the application to potentially update. The `cy.get()` queries the application's DOM, finds the elements that match the selector, and then tries the assertion that follows it (in our case `should('have.length', 2)`) against the list of found elements.
 
 - ✅ If the assertion that follows the `cy.get()` command passes, then the command finishes successfully.
-- 🚨 If the assertion that follows the `cy.get()` command fails, then the `cy.get()` command will requery the application's DOM again. Then Cypress will try the assertion against the elements yielded from `cy.get()`. If the assertion still fails, `cy.get()` will try requery the DOM again, and so on until the `cy.get()` command timeout is reached.
+- 🚨 If the assertion that follows the `cy.get()` command fails, then the `cy.get()` command will requery the application's DOM again. Then Cypress will try the assertion against the elements yielded from `cy.get()`. If the assertion still fails, `cy.get()` will try requerying the DOM again, and so on until the `cy.get()` command timeout is reached.
 
 The retry-ability allows the tests to complete each command as soon as the assertion passes, without hard-coding waits. If your application takes a few milliseconds or even seconds to render each DOM element - no big deal, the test does not have to change at all. For example, let's introduce an artificial delay of 3 seconds when refreshing the application's UI below in an example TodoMVC model code:
 
@@ -105,7 +105,7 @@ Cypress only retries commands that query the DOM: {% url `cy.get()` get %}, {% u
 Commands are not retried when they could potentially change the state of the application under test. For example, Cypress will not retry the {% url '.click()' click %} command, because it could change something in the application.
 
 {% note warning %}
-Very rarely you may want to retry a command like `.click()`. We describe one case like that where the event listeners are attached to a modal popup only after a delay, the causing default events fired during `.click()` to not register. In this special case you may want to "keep clicking" until the event registers, and the dialog disappears. Read about it in the {% url "When Can the Test Click?" https://www.cypress.io/blog/2019/01/22/when-can-the-test-click/ %} blog post.
+Very rarely you may want to retry a command like `.click()`. We describe one case like that where the event listeners are attached to a modal popup only after a delay, thus causing default events fired during `.click()` to not register. In this special case you may want to "keep clicking" until the event registers, and the dialog disappears. Read about it in the {% url "When Can the Test Click?" https://www.cypress.io/blog/2019/01/22/when-can-the-test-click/ %} blog post.
 {% endnote %}
 
 # Built-in assertions
@@ -297,10 +297,10 @@ it('adds two items', function () {
 
 {% imgTag /img/guides/retry-ability/alternating.png "Passing test" %}
 
-The test passes, because the second `cy.get('.todo-list li')` is retried with its own assertion now `.should('have.length', 2)`. Only after successfully finding two `<li>` elements, the command `.find('label')` and its assertion starts, and by now, the item with correct "todo B" label has been correctly queried.
+The test passes, because the second `cy.get('.todo-list li')` is retried with its own assertion now `.should('have.length', 2)`. Only after successfully finding two `<li>` elements, the command `.find('label')` and its assertion starts, and by now, the item with the correct "todo B" label has been correctly queried.
 
 # See also
 
-- You can add retry-ability to your own {% url "custom commands" custom-commands %}, see {% url 'this pull request to cypress-xpath' https://github.com/cypress-io/cypress-xpath/pull/12/files %} for an example.
+- You can add retry-ability to your own {% url "custom commands" custom-commands %}; see {% url 'this pull request to cypress-xpath' https://github.com/cypress-io/cypress-xpath/pull/12/files %} for an example.
 - You can retry any function with attached assertions using this 3rd party plugin {% url cypress-pipe https://github.com/NicholasBoll/cypress-pipe %}.
 - See retry-ability examples in the {% url "Cypress should callback" https://glebbahmutov.com/blog/cypress-should-callback/ %} blog post.