diff --git a/source/guides/guides/continuous-integration.md b/source/guides/guides/continuous-integration.md
index 8e25d4f95b..69a3eb3cc1 100644
--- a/source/guides/guides/continuous-integration.md
+++ b/source/guides/guides/continuous-integration.md
@@ -15,6 +15,10 @@ title: Continuous Integration
 
 # Setting up CI
 
+<!-- textlint-disable -->
+{% video youtube saYovXS9Llk %}
+<!-- textlint-enable -->
+
 ## Basics
 
 Running Cypress in Continuous Integration is almost the same as running it locally in your terminal. You generally only need to do two things:
@@ -206,6 +210,10 @@ Caching folders with npm modules saves a lot of time after the first build.
 
 ## CircleCI
 
+<!-- textlint-disable -->
+{% video youtube J-xbNtKgXfY %}
+<!-- textlint-enable -->
+
 ### {% badge success New %} Example CircleCI Orb
 
 The Cypress CircleCI Orb is a piece of configuration set in your `circle.yml` file to correctly install, cache and run Cypress with very little effort.
diff --git a/source/guides/overview/why-cypress.md b/source/guides/overview/why-cypress.md
index 7fae71035a..f09d05a791 100644
--- a/source/guides/overview/why-cypress.md
+++ b/source/guides/overview/why-cypress.md
@@ -10,6 +10,10 @@ title: Why Cypress?
 - Key Cypress features
 {% endnote %}
 
+<!-- textlint-disable -->
+{% video youtube LcGHiFnBh3Y %}
+<!-- textlint-enable -->
+
 # In a nutshell
 
 Cypress is a next generation front end testing tool built for the modern web. We address the key pain points developers and QA engineers face when testing modern applications.
diff --git a/source/guides/tooling/code-coverage.md b/source/guides/tooling/code-coverage.md
index 64a2f02459..bbb0f6cbee 100644
--- a/source/guides/tooling/code-coverage.md
+++ b/source/guides/tooling/code-coverage.md
@@ -10,6 +10,10 @@ title: Code Coverage
 - How to use the code coverage reports to guide writing tests
 {% endnote %}
 
+<!-- textlint-disable -->
+{% video youtube C8g5X4vCZJA %}
+<!-- textlint-enable -->
+
 # Introduction
 
 As you write more and more end-to-end tests, you will find yourself wondering - do I need to write more tests? Are there parts of the application still untested? Are there parts of the application that perhaps are tested too much? One answer to those questions is to find out which lines of the application's source code were executed during end-to-end tests. If there are important sections of the application's logic that **were not** executed from the tests, then a new test should be added to ensure that part of our application logic is tested.
diff --git a/source/guides/tooling/visual-testing.md b/source/guides/tooling/visual-testing.md
index c23dc3b157..668aef3182 100644
--- a/source/guides/tooling/visual-testing.md
+++ b/source/guides/tooling/visual-testing.md
@@ -91,6 +91,10 @@ Listed in the {% url "Visual Testing plugins" plugins#visual-testing %} section.
 
 ## Applitools
 
+<!-- textlint-disable -->
+{% video youtube qVRjhABuyG0 %}
+<!-- textlint-enable -->
+
 {% fa fa-external-link %} {% url "https://applitools.com" https://applitools.com/ %}
 
 Resource |  Description
@@ -102,6 +106,10 @@ Resource |  Description
 
 ## Percy
 
+<!-- textlint-disable -->
+{% video youtube MXfZeE9RQDw %}
+<!-- textlint-enable -->
+
 {% fa fa-external-link %} {% url "https://percy.io" https://percy.io/ %}
 
 Resource |  Description