diff --git a/docs/CONTROL_GROUP_INTERFACE.md b/docs/CONTROL_GROUP_INTERFACE.md
index 573e1a0e4d..1026f99161 100644
--- a/docs/CONTROL_GROUP_INTERFACE.md
+++ b/docs/CONTROL_GROUP_INTERFACE.md
@@ -26,7 +26,7 @@ That means explicitly, that:
 1. The root control group may only be written to by systemd (PID 1). Services that create and manipulate control groups in the top level cgroup are in direct conflict with the kernel's requirement that each control group should have a single-writer only.
 2. Services must set Delegate=yes for the units they intend to manage subcgroups of. If they create and manipulate cgroups outside of units that have Delegate=yes set, they violate the access contract for control groups.
 
-For a more high-level background story, please have a look at this [Linux Foundation News Story](https://www.linuxfoundation.jp/blog/2013/08/all-about-the-linux-kernel-cgroups-redesign/).
+For a more high-level background story, please have a look at this [Linux.com News Story](https://www.linux.com/news/all-about-linux-kernel-cgroups-redesign/).
 
 ### Why this all again?
 
diff --git a/docs/FACTORY_RESET.md b/docs/FACTORY_RESET.md
index bb0e3063b1..d8556957d9 100644
--- a/docs/FACTORY_RESET.md
+++ b/docs/FACTORY_RESET.md
@@ -41,8 +41,7 @@ Specifically, the following concepts are available:
   invalidating all prior keys associated with the security chip and generating
   a new seed key.
 
-* The
-  [`systemd-factory-reset-reboot.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-factory-reset-reboot.service.html)
+* The `systemd-factory-reset-reboot.service`
   unit automatically reboots the system as part of `factory-reset.target`. It
   is ordered after `systemd-tpm2-clear.service` and
   `systemd-factory-reset-request.service` in order to initiate the reboot that
diff --git a/docs/OPTIMIZATIONS.md b/docs/OPTIMIZATIONS.md
index 83a3838a50..676abe0c1d 100644
--- a/docs/OPTIMIZATIONS.md
+++ b/docs/OPTIMIZATIONS.md
@@ -9,7 +9,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
 
 _So you are working on a Linux distribution or appliance and need very fast boot-ups?_
 
-systemd can already offer boot times of < 1s for the Core OS (userspace only, i.e. only the bits controlled by systemd) and < 2s for a complete up-to-date desktop environments on simpler (but modern, i.e. SSDs) laptops if configured properly (examples: [http://git.fenrus.org/tmp/bootchart-20120512-1036.svg](http://git.fenrus.org/tmp/bootchart-20120512-1036.svg)).
+systemd can already offer boot times of < 1s for the Core OS (userspace only, i.e. only the bits controlled by systemd) and < 2s for a complete up-to-date desktop environments on simpler (but modern, i.e. SSDs) laptops if configured properly.
 
 In this page we want to suggest a couple of ideas how to achieve that, and if the resulting boot times do not suffice where we believe room for improvements are that we'd like to see implemented sooner or later.