Switching From Manual Ads to AdSense Auto Ads: How a Technical Blog Balances Revenue, Code Blocks, and Reading Experience

Recently, I have been re-evaluating my blog’s ad monetization strategy.

After trying Wanwei Ads, Media.net, and reviewing historical data from the Baidu Union, I gradually realized a practical issue:

For an independent technical blog with traffic primarily from mainland China, finding a platform that is significantly better than Google AdSense, supports Chinese content, accepts low-to-medium traffic websites, and offers a relatively normal ad experience is not easy.

Rather than continuing to search for an uncertain new platform, it is better to first re-evaluate the existing AdSense.

In the past, I always used manual ad units:

• Fixed ad units on the homepage;
• In-article ads inserted at specified positions on article detail pages;
• Managing ad code via WPCode;
• Trying to prevent ads from affecting code blocks and article formatting.

This approach was relatively controllable, but it had one obvious issue:

Ad placements relied entirely on manual design and could not dynamically adjust based on different article lengths, screen sizes, and page structures.

In some very long technical articles, there might be only one manual ad unit in the body text; while on other pages, ads might not be in the most valuable positions.

Therefore, this time I decided to make a new attempt:

Disable existing manual ad units, keep only the AdSense site-wide base code, and then enable auto ads.

My bottom line was also clear:

1. Ads can be automatically inserted into article detail pages;
2. Anchor ads and interstitial ads are acceptable;
3. A relatively aggressive ad density is acceptable;
4. But ads must not be inserted inside code blocks;
5. And they must not severely disrupt the reading structure of technical articles.

1. Why I Was Willing to Try Auto Ads This Time

I used to be cautious about auto ads, mainly worrying about the following issues:

• Uncontrolled number of ads;
• Ads being inserted into code blocks;
• Technical articles being fragmented too much;
• Deteriorating mobile page experience;
• Auto ads duplicating existing manual ads.

However, the actual situation of the website has now changed.

On one hand, the site has accumulated a large amount of content, and the page structures are very complex:

• Code Block Pro;
• SyntaxHighlighter;
• Native Gutenberg code blocks;
• <pre> and <code> in the Classic Editor;
• Images, lists, tables;
• Series article directories;
• A large amount of legacy formatting from historical articles.

The time cost of continuing to rely on manual design for the optimal ad placement for every page structure is becoming increasingly high.

On the other hand, the vast majority of visits go directly to article detail pages. If ads are only placed on the homepage, sidebar, or end of articles, many visitors might only generate a single, very limited ad impression.

So, the goal of this test was not “to place as few ads as possible,” but rather:

To let AdSense fully utilize the ad inventory on article detail pages without inserting ads into code blocks.

2. Step One: Disable All Manual Ad Units

I first disabled all manual ad codes in WPCode.

Manual ad codes typically contain the following structures:

<ins class="adsbygoogle"
     data-ad-client="ca-pub-xxxxxxxxxxxxxxxx"
     data-ad-slot="xxxxxxxxxx">
</ins>

<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

<ins class="adsbygoogle"
     data-ad-client="ca-pub-xxxxxxxxxxxxxxxx"
     data-ad-slot="xxxxxxxxxx">
</ins>

<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

Here, data-ad-slot corresponds to a specific fixed ad unit.

After disabling these codes, only a single AdSense site-wide base script remained in WPCode:

<script async
  src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-xxxxxxxxxxxxxxxx"
  crossorigin="anonymous">
</script>

<script async
  src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-xxxxxxxxxxxxxxxx"
  crossorigin="anonymous">
</script>

The settings for this code are:

• Code Type: HTML Snippet;
• Insert Method: Auto Insert;
• Location: Site Wide Header;
• Status: Active.

It is not a specific ad unit itself; it only loads the AdSense script across the site, so it still needs to be retained for auto ads.

3. After Disabling the Code, Old Ads Still Appeared in the Webpage Source Code

After disabling the manual ad codes, I went to the AdSense auto ads preview page and found that the bottom of the page still displayed:

Existing AdSense ads

Existing AdSense ads

Upon further inspecting the webpage source code of the article detail page, I could still search for the old ad unit:

<ins class="adsbygoogle"
     style="display:block; text-align:center;"
     data-ad-layout="in-article"
     data-ad-format="fluid"
     data-ad-client="ca-pub-xxxxxxxxxxxxxxxx"
     data-ad-slot="8627057919">
</ins>

<ins class="adsbygoogle"
     style="display:block; text-align:center;"
     data-ad-layout="in-article"
     data-ad-format="fluid"
     data-ad-client="ca-pub-xxxxxxxxxxxxxxxx"
     data-ad-slot="8627057919">
</ins>

Since this ad unit ID could not be found by searching within the WordPress article code editor, it can be confirmed that:

The ad code was not written into the article body.

The most likely remaining cause is caching.

My website simultaneously uses:

• W3 Total Cache page cache;
• W3TC Redis object cache;
• EdgeOne edge cache;
• Different domains for the Chinese site and the English site.

Therefore, disabling the WPCode did not mean that all historical HTML would disappear immediately.

4. Clearing Server-Side Cache for the Chinese and English Sites

To rule out the W3TC page cache and object cache, I uniformly cleared both the Chinese and English sites on the server:

cd /data/wwwroot/www.shuijingwanwq.com

all_ok=1

for host in \
  "www.shuijingwanwq.com" \
  "en.shuijingwanwq.com"
do
    echo
    echo "========== 清理 $host =========="

    page_cache_dir="wp-content/cache/page_enhanced/$host"

    echo "1. 清理对象缓存"
    if /root/bin/w3tc-flush-host-object-cache "$host"; then
        echo "对象缓存清理命令：成功"
    else
        echo "对象缓存清理命令：失败"
        all_ok=0
    fi

    echo "2. 删除对象缓存操作后可能重新生成的页面缓存"
    rm -rf -- "$page_cache_dir"

    if [[ ! -e "$page_cache_dir" ]]; then
        echo "页面缓存清理验证：通过"
    else
        echo "页面缓存清理验证：失败"
        all_ok=0
    fi
done

echo

if [[ "$all_ok" -eq 1 ]]; then
    echo "www 与 en 的服务器端页面缓存、对象缓存均已清理。"
else
    echo "存在清理异常，但当前 SSH 会话不会退出。"
fi

cd /data/wwwroot/www.shuijingwanwq.com

all_ok=1

for host in \
  "www.shuijingwanwq.com" \
  "en.shuijingwanwq.com"
do
    echo
    echo "========== 清理 $host =========="

    page_cache_dir="wp-content/cache/page_enhanced/$host"

    echo "1. 清理对象缓存"
    if /root/bin/w3tc-flush-host-object-cache "$host"; then
        echo "对象缓存清理命令：成功"
    else
        echo "对象缓存清理命令：失败"
        all_ok=0
    fi

    echo "2. 删除对象缓存操作后可能重新生成的页面缓存"
    rm -rf -- "$page_cache_dir"

    if [[ ! -e "$page_cache_dir" ]]; then
        echo "页面缓存清理验证：通过"
    else
        echo "页面缓存清理验证：失败"
        all_ok=0
    fi
done

echo

if [[ "$all_ok" -eq 1 ]]; then
    echo "www 与 en 的服务器端页面缓存、对象缓存均已清理。"
else
    echo "存在清理异常，但当前 SSH 会话不会退出。"
fi

The final output showed:

Server-side page cache and object cache for both www and en have been cleared.

Server-side page cache and object cache for both www and en have been cleared.

5. Verifying Origin Server and EdgeOne Public Network Responses Separately

After clearing the server-side cache, instead of relying solely on browser refreshes, I made separate requests to:

1. The origin server, bypassing EdgeOne;
2. The normal public address going through EdgeOne.

The test article was:

https://www.shuijingwanwq.com/2026/07/22/19885/

https://www.shuijingwanwq.com/2026/07/22/19885/

I executed the command:

cd /data/wwwroot/www.shuijingwanwq.com

path='/2026/07/22/19885/'
slot='8627057919'
test_id="$(date +%s)"

echo "========== 1. 直接访问源站，绕过 EdgeOne =========="
curl -k -sS \
  --resolve "www.shuijingwanwq.com:443:127.0.0.1" \
  -H 'Cache-Control: no-cache' \
  "https://www.shuijingwanwq.com${path}?swq_ad_test=${test_id}" \
| grep -n -C 3 -- "$slot" \
|| echo "源站未发现旧广告位：$slot"

echo
echo "========== 2. 通过公网访问，经过 EdgeOne =========="
curl -sS \
  -H 'Cache-Control: no-cache' \
  "https://www.shuijingwanwq.com${path}?swq_ad_test=${test_id}" \
| grep -n -C 3 -- "$slot" \
|| echo "公网页面未发现旧广告位：$slot"

cd /data/wwwroot/www.shuijingwanwq.com

path='/2026/07/22/19885/'
slot='8627057919'
test_id="$(date +%s)"

echo "========== 1. 直接访问源站，绕过 EdgeOne =========="
curl -k -sS \
  --resolve "www.shuijingwanwq.com:443:127.0.0.1" \
  -H 'Cache-Control: no-cache' \
  "https://www.shuijingwanwq.com${path}?swq_ad_test=${test_id}" \
| grep -n -C 3 -- "$slot" \
|| echo "源站未发现旧广告位：$slot"

echo
echo "========== 2. 通过公网访问，经过 EdgeOne =========="
curl -sS \
  -H 'Cache-Control: no-cache' \
  "https://www.shuijingwanwq.com${path}?swq_ad_test=${test_id}" \
| grep -n -C 3 -- "$slot" \
|| echo "公网页面未发现旧广告位：$slot"

The result was:

Old ad unit not found on origin server: 8627057919
Old ad unit not found on public network page: 8627057919

Old ad unit not found on origin server: 8627057919
Old ad unit not found on public network page: 8627057919

Subsequently, after viewing the webpage source code in the browser using a new random parameter, the old ad unit could no longer be found either.

This indicates that:

• WPCode has stopped inserting manual ads;
• The W3TC page cache has been updated;
• There are no manual ads in the origin server HTML;
• There are no manual ads in the EdgeOne public network response either.

6. The Homepage Also Has No Manual Ads, but the Preview Still Shows “Existing Ads”

Since AdSense previews the homepage by default, and the homepage and article detail pages originally used different ad units, I needed to check the homepage separately.

I saved the origin server homepage and the public network homepage separately:

cd /data/wwwroot/www.shuijingwanwq.com

origin_file="/tmp/swq-home-origin.html"
public_file="/tmp/swq-home-public.html"

curl -k -sS \
  --resolve "www.shuijingwanwq.com:443:127.0.0.1" \
  -H 'Cache-Control: no-cache' \
  "https://www.shuijingwanwq.com/" \
  -o "$origin_file"

curl -sS \
  "https://www.shuijingwanwq.com/" \
  -o "$public_file"

for file in "$origin_file" "$public_file"
do
    echo
    echo "========== 检查：$file =========="

    echo "--- data-ad-slot ---"
    grep -oE 'data-ad-slot=["'\''][^"'\'']+["'\'']' "$file" \
      | sort -u \
      || true

    echo
    echo "--- 手动广告单元相关行 ---"
    grep -nE 'class=["'\''][^"'\'']*adsbygoogle|data-ad-slot=|data-ad-layout=|data-ad-format=' "$file" \
      | head -n 40 \
      || true
done

cd /data/wwwroot/www.shuijingwanwq.com

origin_file="/tmp/swq-home-origin.html"
public_file="/tmp/swq-home-public.html"

curl -k -sS \
  --resolve "www.shuijingwanwq.com:443:127.0.0.1" \
  -H 'Cache-Control: no-cache' \
  "https://www.shuijingwanwq.com/" \
  -o "$origin_file"

curl -sS \
  "https://www.shuijingwanwq.com/" \
  -o "$public_file"

for file in "$origin_file" "$public_file"
do
    echo
    echo "========== 检查：$file =========="

    echo "--- data-ad-slot ---"
    grep -oE 'data-ad-slot=["'\''][^"'\'']+["'\'']' "$file" \
      | sort -u \
      || true

    echo
    echo "--- 手动广告单元相关行 ---"
    grep -nE 'class=["'\''][^"'\'']*adsbygoogle|data-ad-slot=|data-ad-layout=|data-ad-format=' "$file" \
      | head -n 40 \
      || true
done

The results showed:

• The origin server homepage does not have data-ad-slot;
• The public network homepage does not have data-ad-slot;
• Neither side has <ins class="adsbygoogle">;
• And neither has data-ad-layout and data-ad-format.

In other words, the actual website no longer has manual ads.

However, the AdSense preview interface still retained the placeholder for “Existing AdSense ads”.

This might be related to the following reasons:

• AdSense preview cache;
• The Google crawl node being different from the current test node;
• Different cache update times across EdgeOne edge nodes;
• A delay in AdSense recognizing the page’s historical ad structure.

Since new requests from the origin server, the public network, and the browser had all confirmed the absence of manual ads, I ultimately decided not to spend more time troubleshooting this preview prompt.

7. Officially Turning On the Auto Ads Master Switch

After completing the manual ad cleanup, I turned on the AdSense auto ads master switch.

Once enabled, the current account provided the following three types of ad formats:

• Intention-driven ad formats;
• Overlay ad formats;
• In-page ad formats.

Next, I needed to configure each item individually rather than using the default settings directly.

8. Disabling Intention-Driven Ad Formats

Intention-driven ads actively modify existing webpage content, including:

• Inserting ad intention links into existing text;
• Placing ad intention anchors on the page;
• Adding ad intention bar tags at the end of paragraphs.

For ordinary information websites, this approach might increase ad interaction.

But technical blogs contain a large amount of:

• Technical terms;
• Product names;
• Plugin names;
• Commands;
• Paths;
• API names;
• Code explanations.

If the system automatically turns these into ad links, it can easily disrupt reading and might make technical articles look unprofessional.

Therefore, I turned off the entire intention-driven ad format:

Intention-driven ad formats: 0/1

Intention-driven ad formats: 0/1

9. Overlay Ads: Bottom Anchor Ads and High-Frequency Interstitial Ads

Overlay ads do not insert into the body text but cover the page content from above, so they have less impact on the code block structure.

This part includes:

• Anchor ads;
• Vignette ads;
• Interstitial ads.

1. Anchor Ads

I kept anchor ads and set them as follows:

• Allow dynamic anchor ads;
• Allow display on desktop screens wider than 1000 pixels;
• Ad position restricted to the bottom.

The reason for choosing the bottom is that top ads easily end up close to:

• The site title;
• The search box;
• The language switcher;
• The navigation menu.

Bottom anchor ads are less likely to disrupt the page structure and will not insert into code blocks.

2. Vignette Ads

Vignette ads are temporarily disabled.

Although my site has a high proportion of desktop traffic, the page itself already has a sidebar, widgets, and content navigation. Not enabling them in the first test avoids making the left and right areas of the page too crowded.

3. Interstitial Ads

I decided to enable interstitial ads.

My reasoning was:

If a user is willing to click another link on the site, it shows an intention to continue reading other articles. Displaying an interstitial ad during the page transition is more acceptable than directly interrupting the current article body.

The interstitial ads were ultimately configured as:

• Interstitial ads: Enabled;
• Display frequency: 1 minute;
• Additional trigger conditions: Disabled;
• Desktop screens wider than 1000 pixels: Enabled.

A clarification is needed here:

1 minute does not mean that an ad will definitely appear every time a user clicks a link.

It represents the shortest interval between two interstitial ads for the same user. Whether it ultimately displays is still decided by AdSense based on ad inventory, user status, and page navigation.

I chose 1 minute because this test itself is revenue-prioritized, and I did not intend to start with an overly conservative frequency.

10. Enabling All In-Page Ad Formats

In-page ads are the most important part of this test.

Because the vast majority of the site’s traffic goes directly to article detail pages. If in-page ads were disabled, keeping only anchor ads and interstitial ads, many visitors who read just one article and leave might only generate a single anchor ad impression, or even no interstitial ad at all.

This would likely be worse than the original manual in-article ads.

Therefore, I enabled all three in-page formats:

• Display ads;
• Multi-ad;
• Related searches.

Display Ads

Display ads are the primary auto ad format within the article body.

They find suitable ad positions based on the main content of the page and are the core of auto ads replacing the original manual in-article ads.

Multi-ad

Multi-ad displays native ads in a grid format.

It is more suitable for appearing:

• Near the end of an article;
• Between series directories;
• In standalone sections within long content.

Related Searches

Related searches mainly support English pages.

The Chinese site might not display them, but the English site en.shuijingwanwq.com has the opportunity to add new ad entry points, so I also kept them enabled.

Related searches do not simply generate revenue based on impressions; instead, they guide users to a related search page and monetize through subsequent ad interactions.

It is more of an incremental supplement for the English site rather than a primary ad format.

11. The Initial 200px Spacing Caused Ads in the Series Directory to Be Too Dense

Initially, I set the in-page ads to:

• Max ads per page: Medium-high;
• Min ad spacing: 200px;
• Find more ad positions on article pages: Enabled;
• Allow Google to optimize existing ads: Disabled.

To verify the code blocks and historical article structure, I chose a long article from 2018:

https://www.shuijingwanwq.com/2018/04/13/2597/

https://www.shuijingwanwq.com/2018/04/13/2597/

This article contains:

• A series directory with 13 headings;
• Multiple long code blocks;
• Images;
• A large number of continuous technical steps;
• Legacy article formatting.

In the desktop preview, a total of 14 in-page ads were expected to appear throughout the article.

No ads were inserted inside the code blocks, which was ideal.

However, the ad density within the series heading list was clearly too high.

Out of 13 series headings, the system estimated inserting 7 ads, meaning an ad appeared almost every one or two headings.

12. Excluding Areas One by One Is Impractical

The AdSense preview supports clicking the ban icon next to an ad to add an area to “Excluded areas”.

But upon actual operation, I found that the space between every two series headings was recognized as an independent area.

If excluded one by one, a large number of areas would need to be maintained:

• Area 1;
• Area 2;
• Area 3;
• ……
• Area 10.

Moreover, such rules might only apply to pages with similar layouts.

The site contains many articles with different topics, different editors, and different legacy structures. Relying on excluding areas one by one is not a maintainable long-term solution.

Therefore, I gave up on excluding them one by one and instead adjusted the global minimum ad spacing.

13. Adjusting the Minimum Ad Spacing to 530px

After multiple previews, I ultimately increased the minimum ad spacing from:

200px

200px

to:

530px

530px

The adjusted desktop effect was:

• In-page ads for the entire article decreased from 14 to 10;
• 3 ads appeared among the 13 series headings;
• An ad appeared approximately every 4 to 5 headings;
• No ads entered the interior of code blocks;
• Sufficient ad display opportunities were retained within the body text.

This result basically met expectations:

No longer overly crowded, but also not turning off all ads on article detail pages just to be safe.

530px is not a universal answer applicable to all websites; it is simply a compromise derived from my page structure and preview results.

14. Mobile Ads Are Denser Than Desktop, but Temporarily Acceptable

After switching to the mobile preview, the same article was expected to show 15 in-page ads, which is more than the 10 on desktop.

From the screenshot, the mobile ad density is indeed on the high side.

However, the vast majority of my site’s visitors come from desktop, and the mobile proportion is low. At the same time, this is a very long historical article, and the 15 ads are the total candidates for the entire page, not all displayed simultaneously on the first screen.

More importantly:

• No ads were inserted into code blocks;
• The body text was not obscured;
• The page structure was not noticeably broken;
• Anchor ads were located at the bottom;
• Interstitial ads were only triggered during page transitions.

Therefore, I temporarily accept this mobile performance and will first observe through actual running data, rather than continuing to lower the ad density for the entire site for the sake of a small amount of mobile traffic.

15. Final Auto Ads Configuration

The configuration officially applied this time is as follows.

Auto Ads Master Switch

Enabled

Enabled

Intention-Driven Ad Formats

Disabled

Disabled

Overlay Ad Formats

Anchor ads:

• Enabled;
• Dynamic anchor ads enabled;
• Desktop widescreen display enabled;
• Bottom only.

Vignette ads:

Disabled

Disabled

Interstitial ads:

• Enabled;
• Frequency 1 minute;
• Additional trigger conditions disabled;
• Desktop widescreen display enabled.

In-Page Ad Formats

• Display ads: Enabled;
• Multi-ad: Enabled;
• Related searches: Enabled.

Advanced settings:

• Max ads per page: Medium-high;
• Min ad spacing: 530px;
• Find more ad positions on article pages: Enabled;
• Allow Google to optimize existing ads: Disabled.

16. Why I Chose “Apply Now” Instead of Running an Experiment

After clicking “Apply to site”, AdSense provided two options:

1. Apply now;
2. Run an experiment first.

The experiment mode would take 50% of the site’s traffic and run for up to 90 days to compare the new and old settings.

But my manual ad codes had all been disabled.

If I ran an experiment, part of the traffic in the old settings group might not have normal manual ads, while only the new settings group would have auto ads enabled. The results obtained this way would not be a fair comparison:

• One group with auto ads;
• The other group with almost no ads.

Therefore, I chose:

Apply now

Apply now

Then clicked save.

Figure 18: Selecting apply now to directly apply the auto ads configuration to the entire site.

This time, there was no need to modify WPCode again, nor was there a need to clear the W3TC or EdgeOne cache due to the AdSense configuration change.

The base script already existed in the page, and the auto ads configuration would be dynamically loaded by AdSense.

17. What This Test Actually Solved

This adjustment was not just “replacing manual ads with auto ads”.

It solved several long-standing issues.

1. No Longer Manually Maintaining Multiple Fixed Ad Units

The homepage, article pages, and different legacy templates no longer need to maintain different data-ad-slot separately.

2. Long Articles Can Get More Ad Opportunities

The system can automatically find positions based on article length and structure, rather than all articles having only one fixed ad.

3. Code Block Risk Initially Verified

At least in this historical article containing long code blocks, no ads were inserted inside the code blocks.

This proves that AdSense has a certain ability to recognize the current code structure.

4. Solving Locally Excessive Ad Density via Spacing

Rather than maintaining a dozen excluded areas, using a 530px global minimum spacing to control overall density incurs lower maintenance costs.

5. More Diverse Ad Formats

Currently, it simultaneously includes:

• Article page display ads;
• Multi-ad;
• Related searches on the English site;
• Bottom anchor ads;
• Interstitial ads during page transitions.

This has more testing value than the single manual in-article ad from the past.

18. Issues That Still Need Continued Observation

The official activation of auto ads does not mean the work is finished.

Next, at least the following items need to be observed.

1. Whether Other Legacy Code Formats Are Incorrectly Inserted with Ads

The current test page did not show ads within code blocks, but the site also has:

• SyntaxHighlighter;
• Native Gutenberg Code;
• Code Block Pro;
• Classic <pre>;
• Other legacy code plugins.

Different historical articles need to be continuously spot-checked.

2. Whether the Actual Number of Ads Matches the Preview

The preview shows candidate ad positions, and in real visits, not every position will necessarily be filled with an ad.

The final number will be affected by:

• Ad inventory;
• User region;
• Device;
• Page content;
• Ad blocking;
• AdSense real-time policies;

and other factors.

3. Whether Interstitial Ads Are Too Frequent

Although the frequency is set to 1 minute, whether they actually appear on every intra-site navigation needs to be observed through real visits.

If they noticeably affect return visits or continuous reading, I will adjust it to 5 minutes or longer.

4. Whether the Mobile Experience Is Acceptable

The number of ads in the mobile preview is high.

Although mobile traffic accounts for a low proportion, it is still necessary to check:

• Whether the body text is obscured;
• Whether it causes layout shifts;
• Whether it affects horizontal code scrolling;
• Whether too many consecutive ads appear.

5. Whether Revenue Is Actually Higher Than Manual Ads

This is the ultimately most important question.

This article will not disclose specific AdSense revenue data, but subsequent data after running for a period will be used to compare:

• Page RPM;
• Ad impressions;
• Coverage of ad requests;
• Anchor ad performance;
• Interstitial ad performance;
• Differences between the Chinese and English sites;
• Overall changes before and after enabling auto ads.

19. Phased Conclusion

Through this adjustment, I ultimately did not abandon Google AdSense, nor did I immediately switch to a more aggressive third-party auto ad platform.

Instead, I first transformed AdSense itself into an automated ad solution.

The entire process included:

1. Disabling all manual ad units;
2. Retaining the site-wide AdSense base script;
3. Clearing W3TC page cache and object cache;
4. Verifying that the origin server and EdgeOne no longer have old ads;
5. Enabling auto ads;
6. Disabling intention-driven ads;
7. Enabling bottom anchor ads;
8. Enabling interstitial ads with a 1-minute frequency;
9. Enabling all in-page ad formats;
10. Verifying that ads did not enter code blocks;
11. Adjusting the minimum ad spacing from 200px to 530px;
12. Choosing to apply to the site immediately.

The final solution can be summarized as:

Ad density is somewhat aggressive, but it tries not to modify the semantic meaning of the body text and does not insert inside code blocks.

This is not the final answer, but merely a new round of practical testing.

The next step is to wait for real data and real visitor experiences to determine:

Whether auto ads can produce better results than past manual ads, without noticeably harming the reading experience of technical articles.