讀者看不到文末，就別把內文夾成廣告三明治：把電腦版「空著的兩側」賣出去的 Adsterra 版位設計

1. 「廣告是有的，但讀者不讀到最後就碰不上」，這種尷尬的擺法

文章網站上放了廣告。

顯示也正常。很好。

可是仔細一看，廣告待在文章相當下面的位置。

讀者看標題，看開頭，讀到一半就滿足了，回到搜尋頁，點進別篇文章。

廣告還在下面乾等。

「今天也沒見到半個人。」

這樣一來，廣告雖然在，卻沒辦法把那些只看了上半部就離開的造訪，充分轉成變現的機會。

這時最容易冒出來的想法是：「那就頁面一打開，直接跳一個大廣告出來啊。」

光講道理，確實很快。

但讀者是來看文章的，一進來就被迫先「面試」一輪廣告，這種網站通常會被討厭。

Coalition for Better Ads（更佳廣告聯盟）的研究把電腦版的彈出視窗、附倒數計時的開場全螢幕廣告（prestitial）、佔版面很大的黏性（sticky，捲動時一直黏在螢幕上）廣告等，歸類為使用者不太能接受的廣告體驗。2026 年的更新還新增一項：電腦版內文區域的廣告密度超過 50%，同樣算不達標。^[1][2]

所以問題並不是

「想讓廣告多曝光一點」。

而是

「想在不干擾內文的前提下，把廣告版位挪到讀者自然會經過的地方」。

2. 再看電腦螢幕。「兩邊是不是空得很誇張？」

手機很窄。

光放內文，寬度就不太夠。再塞好幾塊廣告進去，文章馬上變成廣告千層派。

電腦就不一樣了。

為了好讀而把內文寬度縮窄，左右就會留下大片空白。就算把目錄放在側邊欄，目錄的上方和下方也可能是空的。

這時你會發現：

不用在內文裡多塞廣告，旁邊就有一塊閒置的土地。

這與其說是廣告設計，不如說是房地產。

正中間的黃金地段留給內文，讀者走的路不堵住。

把旁邊的空地租出去。

Adsterra 目前列出 160×300、160×600、300×250、320×50、468×60、728×90 等橫幅（Banner）尺寸。官方指南也把 160×600 介紹為適合放在左右兩側的尺寸，把 300×250 介紹為容易融入內文區塊與側邊欄的尺寸。^[3]

所以在電腦版，

廣告
↓
目錄
↓
廣告

這樣的直式配置相當自然。

讀者能讀內文，廣告也看得到。

沒有人需要把看板立在馬路正中間。

3. 電腦版「目錄的上下方」相當好用

舉例來說，如果網站的目錄放在右側邊欄，思路很簡單。

目錄上方

300×250 之類的中型橫幅。

頁面打開後，比較早就有機會進入螢幕。

目錄

文章導覽。

需要的話，只讓目錄黏住（sticky）。

目錄下方

160×600、160×300，或其他符合版面寬度的廣告版位。

文章越長，讀得越深的人，捲動時就越會靠近這個位置。

重點在於，廣告本身不必一直黏著。

大型黏性廣告會在讀者捲動時一直佔著螢幕。依 Coalition for Better Ads 的標準，佔螢幕 30% 以上的大型黏性廣告，在電腦版屬於不達標的廣告體驗。^[2]

所以「利用空著的側邊」和「從旁邊一路追著讀者跑」是兩回事。

賣的是空白。

不追著讀者跑。

光是這樣，格調就高了不少。

4. 頂部也想要廣告。但別把 H1 埋進廣告底下

不只是文末，頁面剛打開的前段位置也想放廣告版位。

即使如此，也沒必要一開始就在頁面最上方放超大橫幅。

比較自然的順序大致是：

文章標題
→ 概要、文章資訊
→ 廣告
→ 目錄、內文

讀者先能確認「這是一篇什麼文章」。

接著出現一則廣告。

然後進入內文。

Adsterra 除了一般橫幅，還有原生橫幅（Native Banner），官方說明它方便網站自行調整區塊大小、顏色與字級。^[4]

不過，「放在上面就一定是 1 個 PV 換一份廣告收益」這種事並不存在。

Adsterra 的廣告除了依千次曝光計費（CPM），還有依點擊計費（CPC）、依轉換行為計費（CPA）等多種計價模式，實際收益會隨廣告需求、國家、裝置、廣告形式、流量品質等而變動。^[3]

準確地說，

把廣告放在靠前的位置，即使讀者沒讀完，也比較容易創造廣告被顯示、被看到的機會。

僅此而已。

它不是「頁面一打開就一定掉一枚金幣的魔法盒」。

5. 別讓廣告姍姍來遲，把內文擠飛

廣告版位一多，又會冒出另一個敵人。

那就是 CLS（累計版面配置位移，頁面內容突然跳動）。

打開頁面。

開始讀內文。

幾秒後，廣告載入。

那塊地方突然撐大到 200px、300px。

正在讀的段落被擠到下面去。

讀著讀著，地板動了。

這體驗相當糟糕。

web.dev 把廣告、iframe、動態插入的元素列為 CLS 的典型成因。對策是在廣告載入之前，就用 min-height 或 aspect-ratio 之類的 CSS 把需要的空間預留起來。^[5]

在 Core Web Vitals（Google 的網頁體驗指標）中，至少 75% 的頁面造訪 CLS 在 0.1 以下，才算良好。^[5]

也就是說，要讓廣告版位成為

載入完才來要座位的客人

是不行的，要讓它成為

一開始就訂好座位的客人。

電腦版側邊的話，先留出 300×250 的盒子；用 160×600 的話，就先佔好那塊直式空間。

廣告來得再晚，內文也不會動。

差別不起眼，影響卻很大。

6. 這裡有個 Adsterra 特有的陷阱。「同一段廣告程式碼，側邊也貼一份不就好了？」

已經有一個廣告版位了。

側邊欄也想要一個。

那就把同一段程式碼複製貼兩次，一下就完成。

可惜，這一點 Adsterra 官方自己就在攔著。

官方指南說明：同一個頁面重複使用同一段橫幅程式碼，可能對統計數據與 CPM 造成不良影響；即使要放兩個相同尺寸的廣告，也請另外準備不同的程式碼。^[6]

同樣的廣告同時出現，對讀者和廣告主來說，畫面都容易顯得怪怪的。

所以最好依用途分別建立獨立的廣告版位（Placement，每個位置各有一段獨立程式碼），例如：

• article-top
• desktop-sidebar-top
• desktop-sidebar-bottom

這樣還有一個好處。

看得出到底哪裡在賺錢。

頂部曝光很多，但 CPM 偏低？

側邊下方曝光少，但單價高？

只有電腦版表現強？

版位分開了，才能比較。

如果把同一段程式碼到處複製，所有數據混成同一個數字，想優化也不知道在優化什麼。

廣告擺放不是「顯示出來就好」，能量測了才算真正的營運。

7. 想自動化的時候，API 突然說「只能看，不能動」

這裡莫名有點好笑。

網站這一側的實作，其實可以自動化很多。

可以把下面這些全部交給 AI 寫程式代理：

• 調查共用的文章版型
• 新增廣告元件
• 只在電腦版顯示側邊廣告
• 手機上隱藏
• 為避免版面位移預留空間
• 建置
• 部署
• 檢查正式環境的 HTML

那 Adsterra 這邊，用 API 建立廣告版位，不就能完全自動化了嗎？

於是去看 Publisher API。

透過 Adsterra 的 Publisher API，可以取得已登錄的網站、廣告版位清單，以及曝光數、點擊數、CTR（點擊率）、CPM、收益等數據。^[7]

確實方便。

但截至 2026 年 9 月 25 日，發布者這一側能用的 HTTP 方法只有 GET。^[7]

也就是說，

能看，
不能建。

Publisher API 當監視器很稱職，但它不是門把手。

要新增廣告單元，還是得在 Publisher 後台選擇網站，按 ADD UNIT 選尺寸，再取得產生的程式碼，這套 GUI（圖形介面）操作少不了。^[8]

自動化完成了 99%，最後那 1% 把人類召喚了出來。

「那麼最後，請按一下這個按鈕。」

文明走到了這一步。

最後剩下的工作，是建立廣告版位的那顆按鈕。

能操作瀏覽器的 AI 代理，也可以把這個 GUI 當作操作對象。只是要清楚一條界線：光靠 Publisher API，沒辦法取代新增廣告版位。

8. 別以為橫幅是自適應的就隨手亂放，手機上會出事

還有一點很重要，就是依裝置區分顯示。

Adsterra 官方的橫幅指南說明，Adsterra 的橫幅不是自適應的，不會隨裝置自動改變尺寸。因此指南介紹了用 CSS 切換電腦版與手機版顯示的方法。^[6]

所以，電腦上 160×600 放得很舒服，就原封不動搬到手機上，會出現

廣告比內文還囂張

的情況。

設計要依裝置分開。

手機

• 文章頂部放一個偏小的廣告
• 需要的話，文末再放一個
• 不顯示側邊廣告
• 不讓廣告搶走內文的寬度

電腦

• 文章頂部廣告
• 目錄上方的側邊廣告
• 目錄下方的側邊廣告
• 原有的文末廣告
• 只有寬度足夠時，才考慮再加側邊區域

不過，電腦版也不是想放多少就放多少。

2026 年新增的 Better Ads Standards（更佳廣告標準）規定，電腦版內文區域廣告密度超過 50% 的體驗算不達標，而且側邊欄（side rail）廣告也會計入密度。^[1]

空白可以賣。

但別搞到四面牆都貼滿海報，把內文變成里民公布欄的地步。

9. 結論：該先賣的是「閒置的空間」，而不是「讀者的注意力」

想增加廣告收益時，最粗糙的辦法就是在內文裡再加廣告。

但電腦版的文章頁，有比這更值得先用的東西。

空白。

內文維持在好讀的寬度。

讓讀者先讀到標題。

靠前的位置放一則廣告。

電腦版在目錄的上下各放獨立的廣告版位。

不用大型黏性廣告追著讀者跑。

事先預留廣告版位的空間，避免版面位移。

別複製同一段橫幅程式碼，依版位拆開，各自量測。

而新增廣告版位這一件事，因為 Publisher API 只支援 GET，只能走後台的 GUI。

作為設計，非常簡單。

不是拿廣告把內文填滿，而是把內文之外閒置的「不動產」租出去。

讀者能讀。

廣告看得見。

網站能比較數據。

廣告主也不必忍受同一個素材同時並排出現兩次。

大家都稍微好過了一點。

最後還剩一件事。

AI 寫完程式碼、改完 CSS、建置、部署、確認完正式環境之後，到廣告公司的後台按一下「新增廣告單元」。

網頁自動化的最終 Boss，大多只是一顆按鈕，這點有點好笑。

參考資料（8筆）

1. Coalition for Better Ads, “CBA Updates Desktop Web and Mobile Web Standards,” announced January 14, 2026; updated desktop standard includes ad density above 50%, with siderail ads included in density calculation. and https://www.betterads.org/desktop-ad-density-over-50-percent betterads.org
2. Coalition for Better Ads, “The Research” and “Large Sticky Ads [Desktop].” and https://www.betterads.org/desktop-large-sticky-ad/ betterads.org
3. Adsterra, “Standard Banner Ad Sizes 2026: Complete Guide with Dimensions,” July 9, 2026 adsterra.com
4. Adsterra, publisher product information for Native Banners, describing customizable block size, colors and font sizes adsterra.com
5. web.dev, “Optimize Cumulative Layout Shift,” last updated February 7, 2025. Ads and dynamically injected content are common CLS sources; reserve space with min-height/aspect-ratio web.dev
6. Adsterra, “Banner Ads Still Drive High CPM and Revenues for Publishers.” Current publisher guidance warns against reusing the same Banner code twice on one page and notes that Adsterra Banners are not automatically responsive across devices adsterra.com
7. Adsterra, “Ad network API” and “Adsterra Publisher API: Easily Pull Data to Power Your Monetization Strategy,” current as checked September 25, 2026. Publisher API exposes websites, placements and performance reports and supports GET only. and https://adsterra.com/blog/how-to-use-adsterra-publishers-api/ adsterra.com
8. Adsterra, “Buy Banner Ads | Adsterra Banner Advertising,” publisher flow: choose a site, ADD UNIT, select Banner size and copy the generated code adsterra.com