diff --git a/.lycheeignore b/.lycheeignore
index 446e814e18..8a7aaae57e 100644
--- a/.lycheeignore
+++ b/.lycheeignore
@@ -1,9 +1,12 @@
+https://biggus.readthedocs.io
 https://cfconventions.org
+https://doi.org/10.3390/jmse2010194
 https://effbot.org
-https://www.personal.psu.edu/cab38/ColorBrewer/ColorBrewer_updates.html
+https://ibm-design-language.eu-de.mybluemix.net/design/language/resources/color-library
+https://geoport.whoi.edu/thredds/dodsC/bathy/gom15
+https://github.com
 https://scitools.github.com/cartopy
-https://biggus.readthedocs.io
 https://stickler-ci.com
 https://www.flaticon.com
-https://doi.org/10.3390/jmse2010194
-https://github.com
+https://www.personal.psu.edu/cab38/ColorBrewer/ColorBrewer_updates.html
+
diff --git a/docs/src/further_topics/dask_best_practices/index.rst b/docs/src/further_topics/dask_best_practices/index.rst
index f126427d3f..9148069198 100644
--- a/docs/src/further_topics/dask_best_practices/index.rst
+++ b/docs/src/further_topics/dask_best_practices/index.rst
@@ -44,13 +44,13 @@ CPU available. This interacts badly with Dask:
 * NumPy will generate enough threads to use all available CPUs even
   if Dask is deliberately configured to only use a subset of CPUs. The
   resulting sharing of CPUs between threads greatly reduces performance.
-* `Dask is already designed to parallelise with NumPy arrays <https://docs
-  .dask.org/en/latest/array.html>`_, so adding NumPy's 'competing' layer of
-  parallelisation could cause unpredictable performance.
+* `Dask is already designed to parallelise with NumPy arrays
+  <https://docs.dask.org/en/latest/array.html>`_, so adding NumPy's 'competing' layer
+  of parallelisation could cause unpredictable performance.
 
 Therefore it is best to prevent NumPy performing its own parallelisation, `a
-suggestion made in Dask's own documentation <https://docs.dask
-.org/en/stable/array-best-practices.html#avoid-oversubscribing-threads>`_.
+suggestion made in Dask's own documentation
+<https://docs.dask.org/en/stable/array-best-practices.html#avoid-oversubscribing-threads>`_.
 The following commands will ensure this in all scenarios:
 
 in Python...
@@ -158,8 +158,8 @@ NetCDF Files
 
 NetCDF files can include their own chunking specification. This is either
 specified when creating the file, or is automatically assigned if one or
-more of the dimensions is `unlimited <https://www.unidata.ucar
-.edu/software/netcdf/docs/unlimited_dims.html>`_.
+more of the dimensions is
+`unlimited <https://www.unidata.ucar.edu/software/netcdf/docs/unlimited_dims.html>`_.
 Importantly, netCDF chunk shapes are **not optimised for Dask
 performance**.
 
diff --git a/docs/src/whatsnew/2.3.rst b/docs/src/whatsnew/2.3.rst
index bec45a6603..91df854c4b 100644
--- a/docs/src/whatsnew/2.3.rst
+++ b/docs/src/whatsnew/2.3.rst
@@ -29,8 +29,7 @@ Features
 .. admonition:: Climatological Coordinate Support
 
   Iris can now load, store and save `NetCDF climatological coordinates
-  <https://cfconventions.org/Data/cf-conventions/cf-conventions-1
-  .7/cf-conventions.html#climatological-statistics>`_. Any cube time
+  <https://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#climatological-statistics>`_. Any cube time
   coordinate can be marked as a climatological time axis using the boolean
   property: ``climatological``. The climatological bounds are stored in the
   coordinate's ``bounds`` property.
@@ -41,9 +40,8 @@ Features
   coordinate's ``bounds`` property are written to a NetCDF boundary variable
   called '<coordinate-name>_bounds'.  These are in place of a standard
   'bounds' attribute and accompanying boundary variable. See below
-  for an `example adapted from CF conventions <https://cfconventions
-  .org/Data/cf-conventions/cf-conventions-1.7/cf-conventions
-  .html#climatological-statistics>`_:
+  for an
+  `example adapted from CF conventions <https://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#climatological-statistics>`_:
 
     .. code-block:: none
 
@@ -116,8 +114,7 @@ Features
 
 * New coordinate system: :class:`iris.coord_systems.Geostationary`,
   including load and save support, based on the `CF Geostationary projection
-  definition <https://cfconventions
-  .org/cf-conventions/cf-conventions.html#_geostationary_projection>`_.
+  definition <https://cfconventions.org/cf-conventions/cf-conventions.html#_geostationary_projection>`_.
 
 * :class:`iris.coord_systems.VerticalPerspective` can now be saved to and
   loaded from NetCDF files.
@@ -164,8 +161,7 @@ Bugs Fixed
   points.
 
 * :class:`iris.coord_systems.VerticalPerspective` coordinate system now uses
-  the `CF Vertical perspective definition <https://cfconventions
-  .org/cf-conventions/cf-conventions.html#vertical-perspective>`_; had been
+  the `CF Vertical perspective definition <https://cfconventions.org/cf-conventions/cf-conventions.html#vertical-perspective>`_; had been
   erroneously using Geostationary.
 
 * :class:`~iris.coords.CellMethod` will now only use valid 
@@ -227,8 +223,7 @@ Internal
 ========
 
 * Iris now supports Proj4 up to version 5, but not yet 6 or beyond, pending
-  `fixes to some cartopy tests <https://github
-  .com/SciTools/cartopy/pull/1289#pullrequestreview-272774087>`_.
+  `fixes to some cartopy tests <https://github.com/SciTools/cartopy/pull/1289#pullrequestreview-272774087>`_.
 
 * Iris now requires Dask >= 1.2 to allow for improved coordinate equality
   checks.