diff --git a/src/code-considerations/breaking-changes/fundamental.md b/src/code-considerations/breaking-changes/fundamental.md
index f0cfe2d..c684927 100644
--- a/src/code-considerations/breaking-changes/fundamental.md
+++ b/src/code-considerations/breaking-changes/fundamental.md
@@ -17,7 +17,7 @@ Typically, the scope of [breakage in new trait impls](./reviewing-code/breakage/
 
 Look out for blanket trait implementations for fundamental types, like:
 
-```rust
+```rust,ignore
 impl<'a, T> PublicTrait for &'a T
 where
     T: SomeBound,
diff --git a/src/code-considerations/breaking-changes/new-trait-impls.md b/src/code-considerations/breaking-changes/new-trait-impls.md
index a95b76c..e717bdc 100644
--- a/src/code-considerations/breaking-changes/new-trait-impls.md
+++ b/src/code-considerations/breaking-changes/new-trait-impls.md
@@ -8,12 +8,12 @@ Also see [`#[fundamental]` types](./fundamental.md) for special considerations f
 
 Rust will use the fact that there's only a single impl for a generic trait during inference. This breaks once a second impl makes the type of that generic ambiguous. Say we have:
 
-```rust
+```rust,ignore
 // in `std`
 impl From<&str> for Arc<str> { .. }
 ```
 
-```rust
+```rust,ignore
 // in an external `lib`
 let b = Arc::from("a");
 ```
@@ -27,7 +27,7 @@ impl From<&str> for Arc<str> { .. }
 
 then
 
-```rust
+```rust,ignore
 let b = Arc::from("a");
 ```
 
@@ -39,14 +39,14 @@ This kind of breakage can be ok, but a [crater] run should estimate the scope.
 
 Rust will use deref coercion to find a valid trait impl if the arguments don't type check directly. This only seems to occur if there's a single impl so introducing a new one may break consumers relying on deref coercion. Say we have:
 
-```rust
+```rust,ignore
 // in `std`
 impl Add<&str> for String { .. }
 
 impl Deref for String { type Target = str; .. }
 ```
 
-```rust
+```rust,ignore
 // in an external `lib`
 let a = String::from("a");
 let b = String::from("b");
@@ -56,14 +56,14 @@ let c = a + &b;
 
 then we add:
 
-```diff
+```diff,ignore
 impl Add<&str> for String { .. }
 + impl Add<char> for String { .. }
 ```
 
 then
 
-```rust
+```rust,ignore
 let c = a + &b;
 ```
 
diff --git a/src/code-considerations/safety-and-soundness/generics-and-unsafe.md b/src/code-considerations/safety-and-soundness/generics-and-unsafe.md
index 4240cd0..972bfcd 100644
--- a/src/code-considerations/safety-and-soundness/generics-and-unsafe.md
+++ b/src/code-considerations/safety-and-soundness/generics-and-unsafe.md
@@ -4,7 +4,7 @@ Be careful of generic types that interact with unsafe code. Unless the generic t
 
 A place where this commonly comes up is with the `RangeBounds` trait. You might assume that the start and end bounds given by a `RangeBounds` implementation will remain the same since it works through shared references. That's not necessarily the case though, an adversarial implementation may change the bounds between calls:
 
-```rust
+```rust,ignore
 struct EvilRange(Cell<bool>);
 
 impl RangeBounds<usize> for EvilRange {
diff --git a/src/code-considerations/safety-and-soundness/may-dangle.md b/src/code-considerations/safety-and-soundness/may-dangle.md
index d5ff641..ad7683c 100644
--- a/src/code-considerations/safety-and-soundness/may-dangle.md
+++ b/src/code-considerations/safety-and-soundness/may-dangle.md
@@ -6,7 +6,7 @@ If a generic `Type<T>` has a manual drop implementation that may also involve dr
 
 As a real-world example of where this can go wrong, consider an `OptionCell<T>` that looks something like this:
 
-```rust
+```rust,ignore
 struct OptionCell<T> {
     is_init: bool,
     value: MaybeUninit<T>,
@@ -25,7 +25,7 @@ impl<T> Drop for OptionCell<T> {
 
 Adding a `#[may_dangle]` attribute to this `OptionCell<T>` that didn't have a `PhantomData<T>` marker field opened up [a soundness hole](https://github.com/rust-lang/rust/issues/76367) for `T`'s that didn't strictly outlive the `OptionCell<T>`, and so could be accessed after being dropped in their own `Drop` implementations. The correct application of `#[may_dangle]` also required a `PhantomData<T>` field:
 
-```diff
+```diff,ignore
 struct OptionCell<T> {
     is_init: bool,
     value: MaybeUninit<T>,
diff --git a/src/code-considerations/using-unstable-lang/const-generics.md b/src/code-considerations/using-unstable-lang/const-generics.md
index 48227c4..15a0312 100644
--- a/src/code-considerations/using-unstable-lang/const-generics.md
+++ b/src/code-considerations/using-unstable-lang/const-generics.md
@@ -10,7 +10,7 @@ Const generics are ok to use in public APIs, so long as they fit in the [`min_co
 
 Look out for const operations on const generics in public APIs like:
 
-```rust
+```rust,ignore
 pub fn extend_array<T, const N: usize, const M: usize>(arr: [T; N]) -> [T; N + 1] {
     ..
 }
@@ -18,7 +18,7 @@ pub fn extend_array<T, const N: usize, const M: usize>(arr: [T; N]) -> [T; N + 1
 
 or for const generics that aren't integers, bools, or chars:
 
-```rust
+```rust,ignore
 pub fn tag<const S: &'static str>() {
     ..
 }
diff --git a/src/code-considerations/using-unstable-lang/specialization.md b/src/code-considerations/using-unstable-lang/specialization.md
index b5421b2..a390b15 100644
--- a/src/code-considerations/using-unstable-lang/specialization.md
+++ b/src/code-considerations/using-unstable-lang/specialization.md
@@ -6,7 +6,7 @@ We try to avoid leaning on specialization too heavily, limiting its use to optim
 
 As an example of how to use specialization in the standard library, consider the case of creating an `Rc<[T]>` from a `&[T]`:
 
-```rust
+```rust,ignore
 impl<T: Clone> From<&[T]> for Rc<[T]> {
     #[inline]
     fn from(v: &[T]) -> Rc<[T]> {
@@ -17,7 +17,7 @@ impl<T: Clone> From<&[T]> for Rc<[T]> {
 
 It would be nice to have an optimized implementation for the case where `T: Copy`:
 
-```rust
+```rust,ignore
 impl<T: Copy> From<&[T]> for Rc<[T]> {
     #[inline]
     fn from(v: &[T]) -> Rc<[T]> {
@@ -28,7 +28,7 @@ impl<T: Copy> From<&[T]> for Rc<[T]> {
 
 Unfortunately we couldn't have both of these impls normally, because they'd overlap. This is where private specialization can be used to choose the right implementation internally. In this case, we use a trait called `RcFromSlice` that switches the implementation:
 
-```rust
+```rust,ignore
 impl<T: Clone> From<&[T]> for Rc<[T]> {
     #[inline]
     fn from(v: &[T]) -> Rc<[T]> {
diff --git a/src/reviewer-checklist.md b/src/reviewer-checklist.md
index 494c3be..a9192c9 100644
--- a/src/reviewer-checklist.md
+++ b/src/reviewer-checklist.md
@@ -6,7 +6,7 @@ Check the [getting started](./getting-started.md) guide for an introduction to d
 
 If you'd like to reassign the PR, you can:
 
-```
+```ignore
 r? @user
 ```
 
@@ -40,12 +40,12 @@ Use [`@bors`](./tools-and-bots/bors.md) to merge the pull request.
 
 To roll up:
 
-```
+```ignore
 @bors r+ rollup
 ```
 
 or just:
 
-```
+```ignore
 @bors r+
 ```
diff --git a/src/tools-and-bots/bors.md b/src/tools-and-bots/bors.md
index 550e297..f52aa1b 100644
--- a/src/tools-and-bots/bors.md
+++ b/src/tools-and-bots/bors.md
@@ -6,7 +6,7 @@ PRs to the standard library aren’t merged manually using GitHub’s UI or by p
 
 You can approve a PR with:
 
-```
+```ignore
 @bors r+
 ```
 
diff --git a/src/tools-and-bots/crater.md b/src/tools-and-bots/crater.md
index a76562e..990c499 100644
--- a/src/tools-and-bots/crater.md
+++ b/src/tools-and-bots/crater.md
@@ -6,18 +6,18 @@
 
 You can kick off a crater run by first calling:
 
-```
+```ignore
 @bors try
 ```
 
 Once that finishes, you can then call:
 
-```
+```ignore
 @craterbot check
 ```
 
 to ensure crates compile, or:
 
-```
+```ignore
 @craterbot run mode=build-and-test
 ```
diff --git a/src/tools-and-bots/timer.md b/src/tools-and-bots/timer.md
index fbb4317..2f7c9b3 100644
--- a/src/tools-and-bots/timer.md
+++ b/src/tools-and-bots/timer.md
@@ -4,6 +4,6 @@
 
 You can kick off a performance test using `@rust-timer`:
 
-```
+```ignore
 @bors try @rust-timer queue
 ```