Patrick Stox
AMA 問答（二）

Hot take, but many of the technical things don't really impact the business bottom line. In almost every audit, there's a handful of things that may have a material impact.

這是個大膽的說法，但很多技術上的事情其實不會影響企業的最終獲利。幾乎每一次稽核，大概都只有少數幾件事可能產生實質影響。

It's usually around indexing, content not being seen because of JavaScript things, maybe hreflang and people ending up on the wrong page, redirects (because why have links you earned going to 404s?), and internal linking opportunities. There may be some situational things like if a site is too slow and people get frustrated and leave, etc.

通常集中在索引、因為 JavaScript 而沒被看到的內容、也許還有 hreflang（讓人落到錯誤的頁面）、轉址（畢竟辛苦賺來的連結，為什麼要導向 404？），以及內部連結的機會。也可能有一些視情況而定的事，例如網站太慢、讓人感到挫折就離開之類。

This type of prioritization comes from years of doing these and seeing the impact. I wouldn't expect people to get it right at first and many tools lead people to believe that some things are more important than they are. When I'm personally presenting these, I normally like to show an impact / effort matrix. As in here's the estimated impact and estimated effort for the fix to help prioritize. Businesses usually immediately understand this.

這種優先順序的判斷，來自多年做這些事、看到實際影響的經驗。我不會期待大家一開始就能抓準，而且很多工具會讓人以為某些事情比實際上更重要。我自己向客戶說明時，通常喜歡用影響／成本矩陣，也就是列出預估的影響，以及修正所需的預估成本，幫助排出優先順序。企業通常馬上就懂。

You said it, be valuable to the business. Put ego aside. That technical fix might make 0 actual business impact, so even if it's a best practice, let it go. Don't even put tickets in the backlog for all the little things. Don't waste time or resources, prioritize what's important, even if that's not technical.

你自己說了，要對企業有價值。把自我放一邊。那個技術修正可能完全不會帶來實際的業務影響，所以就算是最佳實務，也放手吧。甚至不要把所有小事都開成待辦工單。別浪費時間或資源，優先處理重要的事，即使那不是技術性的事。

Beg, plead, ask for log files without IPs which some companies count as PII or only for bots so no user data is there. The reality is that these can be difficult to get even when in-house. They can be expensive to store and analyze as well. The magic word is probably "GEO" or for "AI search". If it's for AI, people are more likely to do things. If a company has an analytics team and you can help them with attribution using the logs especially for AI things, that will likely work to get access.

求、懇求、去要沒有 IP 的紀錄檔（有些公司把 IP 算成個資），或只要機器人的紀錄，這樣就沒有使用者資料。現實是，即使在企業內部，這些也可能很難拿到。儲存與分析可能也很貴。魔法詞大概是「GEO」或「AI 搜尋」。如果是為了 AI，大家比較願意行動。如果公司有分析團隊，你能用紀錄檔幫他們做歸因，特別是 AI 相關的部分，那大概就行得通，能拿到存取權。

That's something that would likely be forecast as 0 or near-0 impact tbh. Search engines have been handling canonicalization for a long time, whether you do it or not. They will usually choose one page to be the indexed version when duplicates exist. This is where best practice vs business impact are at odds. The best way to make the case for that might be with analytics, where having a clean view is easier than compiling different variants or having to filter, so maybe you save some personnel resources and that's the business impact, along with getting cleaner data and getting it faster so you can make decisions faster.

老實說，那種事大概會被預估為零或接近零的影響。搜尋引擎處理 canonical 已經很久了，不管你做不做，有重複頁面時，它們通常會選一個頁面當成索引的版本。這就是最佳實務與商業影響互相衝突的地方。要為此說服人，最好的辦法可能是從分析下手：有乾淨的檢視，比整理不同的變體或必須過濾更容易，所以也許你省下了一些人力，這就是商業影響，加上資料更乾淨、取得更快，能讓你更快做決策。

These days it's a lot of various JavaScript issues, not really just one. Everyone is focused on AI search things, so much of their content isn't really being seen. Or even if it is, there's always other issues like the content not being DOM loaded, where it requires a click for the content to be seen by bots, and bots don't click. Lots of issues with blocked JS files needed for page rendering too.

這些日子是很多不同的 JavaScript 問題，不只一個。大家都專注在 AI 搜尋，所以很多內容其實沒被看到。或者即使有被看到，也總有其他問題，像是內容沒有載入 DOM、需要點擊才能看到內容而機器人不會點擊，還有頁面轉譯所需的 JS 檔被封鎖的問題很多。

Historically I probably would have answered this with redirects because people were changing website URL structures every 1-3 years for a while there, but this is more settled now.

過去我大概會回答是轉址，因為有一陣子大家每一到三年就改一次網站的網址結構，但現在這個情況比較穩定了。

Canonicalization, internationalization, redirects, ACP, UCP, ecommerce feeds, javascript things, migrations, etc.

Canonicalization、國際化、轉址、ACP、UCP、電商 feed、JavaScript 的事、網站遷移等等。

The biggest one I'm running into are mostly around JavaScript. The AI search bots generally don't render (exceptions for the Google and Bing variants). This causes a lot of the content to not be seen, or for them to rely on other 3rd party sources potentially to get your content and not their direct access.

我碰到最大的問題大多跟 JavaScript 有關。AI 搜尋的機器人通常不會轉譯（Google 和 Bing 的版本是例外）。這會導致很多內容沒被看到，或者它們可能轉而依賴其他第三方來源取得你的內容，而不是直接存取。

I already answered one question on prioritization above which I'll link: https://www.reddit.com/r/SEO_for_AI/comments/1xbbkj7/comment/19rhhii405idh/

我在上面已經回答過一個關於優先順序的問題，我把連結放在這裡：https://www.reddit.com/r/SEO_for_AI/comments/1xbbkj7/comment/19rhhii405idh/

As far as changed to accommodate LLMs, as I've also already said JavaScript is more of an issue again because many of them aren't rendering when they crawl. There might also be issues with the accessibility tree which I never would have looked at before, but now I need to because of agentic systems. Situationally there may be things like UCP / ACP that matter now too.

至於為了配合 LLM 而改變的部分，我前面也說過，JavaScript 又變成比較大的問題，因為許多 LLM 爬取時不會轉譯。還有無障礙樹（accessibility tree）可能也有問題，我以前從不會去看它，但現在因為 agent 系統，我需要看。視情況，像 UCP／ACP 這類東西現在也可能重要。

I mean we have some new things to look at with all the WebMCP, ACP, UCP, etc. Log file analysis is having it's day in the sun. JavaScript is an issue again when it was mostly okay for traditional search since they were rendering.

我的意思是，我們有了一些新東西要看，像是 WebMCP、ACP、UCP 等等。紀錄檔分析正迎來它的風光時刻。JavaScript 又變成問題，而在傳統搜尋時代，因為它們會轉譯，所以大致上還算可以。

And as a tech SEO, custom tools. Lots of things that use to take me 5-30 minutes to check, I now have tools I can just call to check the things I would check. That's pretty great.

還有身為技術 SEO，就是自訂工具。很多以前要花我 5 到 30 分鐘檢查的事，現在我有工具可以直接呼叫來檢查我會檢查的東西。這真的很棒。

In general, it could be coming from model memory, it could be a partner (remember RapidAPI?), or it could be their own index (Labrador) which they started using recently. You won't be able to tell it apart in the logs, but I'm pretty sure you can if you break down the result page.

一般來說，可能來自模型記憶，可能來自合作夥伴（還記得 RapidAPI 嗎？），也可能是它們自己的索引（Labrador），它們最近開始使用了。你沒辦法從紀錄檔區分，但我很確定，把結果頁拆開來看，是可以分辨的。

Hey u/tejones01, if I misunderstand part of your questions in my response, please clarify.

嗨 u/tejones01，如果我在回覆裡誤解了你問題的某些部分，請告訴我。

For the key methodologies and frameworks, I generally want that in the relevant content.

關於關鍵方法論和框架，我通常希望把它們放在相關的內容裡。

You glossary question I'm not sure if you mean like definition glossaries are data dictionaries. Glossaries (definition) are still useful and may help at least with brand awareness in citations and all, plus they're easier than ever to create. AI is really good at summarizing things and defining things. I have a basic and extended version on most of the content on my website and a glossary people can browse through that links to these. If you mean the data dictionary part, I mean organization is always important.

你問的詞彙表，我不確定你指的是定義型詞彙表，還是資料字典。定義型詞彙表仍然有用，至少對引用裡的品牌知名度有幫助，而且比以往更容易建立，因為 AI 很擅長摘要和下定義。我網站上大部分內容都有基本版和延伸版，還有一個可瀏覽的詞彙表連到這些內容。如果你指的是資料字典的部分，那麼組織永遠很重要。

For FAQ schema, leave it in place if you have it, but I'm probably not going to recommend adding it if you don't unless you have a system where this is just like ask AI to do it and it gets done. If it takes real time / resources, then nope.

FAQ Schema 的話，如果你已經有就保留，但如果沒有，我大概不會建議新增，除非你有一套系統，只要叫 AI 去做就能完成。如果需要花真正的時間或資源，那就不用。

I mean they could be their own page, but few are likely to get enough traction to really justify that long term. If you consider it more thought leadership content and are fine with that, and then link from the other relevant pages, I would be fine with that kind of approach.

它們可以是各自獨立的頁面，但很少會累積到足夠的流量，長期來看值得這麼做。如果你把它視為思想領導力內容，也能接受，然後從其他相關頁面連過去，我覺得這種做法可以。

I mean your titles and descriptions have always been able to be longer than what is shown in search. Many tests on titles have even shown that longer ones have a positive impact. Google rewrites a large chunk of titles and meta descriptions anyway. I haven't seen tests to show it helps or hurts for AI search, and at a certain point I'm sure it would be deemed spammy, but there may be some middle ground where it works well and it's fine. Try it and let us all know!

我的意思是，你的標題和 meta description 一直都可以比搜尋結果顯示的長。很多標題的測試甚至顯示，較長的標題有正面影響。Google 反正會改寫很大比例的標題和 meta description。我沒看過測試顯示這對 AI 搜尋有幫助或有害，而且到某個程度，我相信會被認為是垃圾，但也許有個中間地帶效果不錯，那也沒問題。試試看，然後讓我們大家知道結果！

Yeah, I wouldn't say do it for SEO but for agents and all, sure. It's still not my favorite approach, and not future-proof imo. I hate that it's a 2nd page with .md files. There's a better version with conditional serving, where it's still the same URL for both. Support for it is small but growing, but typically this kind of thing wins out over 2 versions on 2 URLs.

對，我不會說是為了 SEO 而做，但為了 agent 之類的，當然可以。這仍然不是我最喜歡的做法，我也認為它不是面向未來的。我討厭它是用 .md 檔案多出來的第二個頁面。有個更好的版本是條件式提供（conditional serving），兩種版本用同一個網址。目前支援度還小，但在成長，通常這種做法會贏過兩個網址的兩種版本。

See https://acceptmarkdown.com/status

請見 https://acceptmarkdown.com/status

Only if they have a feature for that type of schema. For general visibility, no.

只有在它們有針對那類 Schema 的功能時才需要。就一般能見度而言，不需要。

No, and I don't believe it will. I mean even for traditional search, it doesn't. It's useful for creating a knowledge graph, and useful for adding features in search. In general I've added when it got me something, as in a search feature or I need to clarify something for the knowledge graph or try to fix some knowledge panel issue. That is how I will continue to use it.

沒有，我也不相信會有。我的意思是，即使在傳統搜尋，也沒有。它對建立知識圖譜有用，也對在搜尋中增加功能有用。一般來說，我是在它能給我帶來東西時才加，比如搜尋功能，或是我需要為知識圖譜釐清什麼，或試圖修正某個知識面板的問題。我之後也會繼續這樣用。

Great study on it here btw from Louise Linehan: https://ahrefs.com/blog/schema-ai-citations/

順帶一提，這裡有 Louise Linehan 做的很棒的研究：https://ahrefs.com/blog/schema-ai-citations/

I saw the study. What's funny is that this kind of benchmark exists as a living data study, updated monthly by Ahrefs for 100k+ websites. Check out https://ahrefs.com/benchmarks/ai-vs-search

我看過那份研究。有趣的是，這種基準其實已經是一份持續更新的資料研究，Ahrefs 每個月針對 10 萬個以上的網站更新。可以看 https://ahrefs.com/benchmarks/ai-vs-search

I sort of agree and sort of disagree with it being a distraction. I mean obviously traffic is lower and much of your search and conversions are going to come from Google, but it doesn't mean AI search isn't playing a role, because it is and that role will increase.

我對「這是分心」有點同意、也有點不同意。顯然流量比較低，你的搜尋與轉換大部分還是會來自 Google，但這不代表 AI 搜尋沒有發揮作用，它有，而且這個角色會增加。

The money is in GEO right now. I'm a big fan of follow the money. There's a large overlap in practice, so take the money, do better SEO.

現在錢在 GEO。我很信奉「跟著錢走」。兩者在實務上有大量重疊，所以，把錢賺進來，把 SEO 做得更好。

For the agentic question, I mean, yes. WebMCP is coming. I'm using bots to do many things on the web for me already. This trend will increase. The question is will websites allow this or start to block them? Hint, many websites are blocking them already.

至於 agent 的問題，我的意思是，會的。WebMCP 要來了。我現在已經在用機器人替我在網路上做很多事，這個趨勢會增加。問題是網站會不會允許這樣，還是開始封鎖？提示一下，很多網站已經在封鎖了。

For the web design question, I'm going to go with no. Now you can do really fun and creative things just by asking. The burden of better design is gone, so if someone wants to do more cool stuff, they can.

至於網頁設計的問題，我的答案是不會。現在你只要開口要求，就能做出非常有趣又有創意的東西。要做出更好設計的負擔已經消失，所以想做更酷東西的人，儘管去做。

Same problem you see in GA4 typically. A lot of the traffic is direct/unknown and out of Singapore. I believe it's the AI crawlers from China who are rendering and accidentally firing analytics. They use Singapore as their gateway. Hopefully the bots learn to block this kind of stuff properly like every crawler in the past who rendered JavaScript, or the analytics tools start filtering it out.

跟你在 GA4 裡通常看到的問題一樣。很多流量是直接／未知，而且來自新加坡。我相信那是來自中國的 AI 爬蟲，它們在轉譯頁面時不小心觸發了分析。它們用新加坡當作出口。希望這些機器人能像過去每個會轉譯 JavaScript 的爬蟲一樣，學會正確封鎖這類東西，或是分析工具開始把它濾掉。

I don't work at Ahrefs anymore, but all the typical analytics scripts are going to be blocked in their crawling, plus they have multiple data centers around the world they crawl from, not just Singapore. The largest one is actually in the US.

我已經不在 Ahrefs 工作了，但所有典型的分析腳本，在它們的爬取中都會被封鎖，而且它們有多個遍布世界各地的資料中心來爬取，不只新加坡。最大的一個其實在美國。

Most of the systems have no link data that I'm aware of. Mentions on the web would be usable, and links probably in the future but I doubt many of the systems are using those yet.

就我所知，大部分的系統沒有連結資料。網路上的提及是可以用的，連結未來可能會，但我懷疑現在有多少系統已經在用這些。

At least for now with the data I've seen, generally people have the same kinds of questions about the same kinds of things they did a few years ago. It takes less research to get to the answers, but people kind of want the same things they have in the past. We may not have as good of data around AI search, but I bet the proportions for the topics that people search haven't really changed that much yet.

至少目前就我看過的資料而言，人們對於同樣的事情，仍然問著和幾年前同樣類型的問題。現在要得到答案需要的研究更少，但人們想要的東西跟過去其實差不多。我們對 AI 搜尋的資料也許沒那麼好，但我猜人們搜尋的主題比例，到目前為止並沒有改變太多。

Do you have a source for SEO is the floor? In my interpretation, what is likely being talked about is that SEO has a huge overlap with GEO, or as Google says, "good SEO is good GEO". And I'm not sure any recent part of SEO has gone obsolete, in fact we seem to be regressing to where spam works again which is unfortunate.

你有「SEO 是地板」的出處嗎？依我的解讀，大家談的可能是 SEO 與 GEO 有很大的重疊，或像 Google 說的「好的 SEO 就是好的 GEO」。我不覺得最近有哪個 SEO 環節已經過時，事實上，我們似乎正在退回到垃圾手法又有效的時代，這很不幸。

I mean, yeah. A lot of the tools are doing fact checking now. If a fact is right in one place, wrong in 5 more, it might write the wrong ones so we end up cleaning it up. I had a slide in a recent presentation that SEOs are the janitors of the internet. Always cleaning stuff up. I don't know that the role changed so much as is being refined since the wrong info can now be output in search.

我的意思是，會的。現在很多工具會做事實查核。如果一個事實在一個地方是對的、在另外五個地方是錯的，它可能會寫出那些錯的，於是我們得去清理。我在最近一場簡報裡有一張投影片說，SEO 是網路的清潔工，總是在清理東西。我不覺得這個角色改變了多少，比較像是被精煉了，因為錯誤資訊現在可以在搜尋裡被輸出。

It's messy and there are all kinds of things you could do for fuzzy matching the data. It really is a case of get as much data as you can and try to figure it out, or ultimately just ignore the data and look at conversions/leads/revenue and if numbers go up, don't spend so much of your time trying to measure it. A lot of companies spend more time measuring than doing things that would have a real business impact. They argue they need the data to make better decisions, but the better decision is really do more things that will have an impact and spend less resources trying to measure it.

很亂，有各種模糊比對資料的做法。現實就是盡量蒐集資料並設法弄清楚，或者最終乾脆忽略資料，看轉換／名單／營收，如果數字上升，就不用花那麼多時間去衡量。很多公司花在衡量上的時間，比做真正有業務影響的事還多。他們會爭辯說需要資料才能做更好的決策，但真正更好的決策，是多做有影響的事，少花資源去衡量。

The reality is the data is bad and generally getting worse. This is a trend for about as long as I can remember. As the world moves towards privacy, data and attribution get worse. It doesn't help that many of these systems don't pass a referer (intentially spelled this way because that's how it is in the spec) value. I did a study last year and ones like ChatGPT had gaps at the time that they cleaned up, which means somewhere there maybe read that study? The study: https://ahrefs.com/blog/generative-engines-are-breaking-web-analytics/

現實是資料很差，而且通常越來越差。就我記憶所及，這個趨勢已經存在很久了。隨著世界走向隱私，資料與歸因會越來越差。很多這類系統不傳遞 referer（刻意這樣拼，因為規格裡就是這樣）值，更沒幫助。我去年做了一項研究，像 ChatGPT 當時有缺口，後來它們清掉了，也就是說也許有人讀了那篇研究？研究在這裡：https://ahrefs.com/blog/generative-engines-are-breaking-web-analytics/

As for where to start, whatever you can get. Sometimes logs are hard to get, many times panel data will be impossible for companies to get because of costs and all. So probably of the ones you mentioned, the analytics data > log files > panel data.

至於從哪裡開始，就是你能拿到什麼就用什麼。有時紀錄檔很難拿，很多時候面板資料因為成本等因素，企業根本拿不到。所以在你提到的這些之中，大概是分析資料 > 紀錄檔 > 面板資料。

I'd move it. As you said, .ch would be a strong geo targeting signal that you want to rank in Switzerland.

我會搬。就像你說的，.ch 會是很強的地理定位訊號，會讓你在瑞士排名。

Doesn't have to be a .com, but a generic tld will be better. There are some famous case studies showing success of this though, especially from UK sites.

不一定要是 .com，但通用的 TLD 會比較好。有些著名的案例研究顯示這麼做很成功，尤其是來自英國的網站。

I don't recall off the top of my head. A quick search yielded this which I did not verify: https://digitaloft.co.uk/case-studies/outdoor-toys

我一時想不起來。快速搜尋找到這個，但我沒有驗證：https://digitaloft.co.uk/case-studies/outdoor-toys

I wouldn't trust the GSC data here. They consolidate the URLs to one for reporting. I think it's based on the returned page when they do the main query, so a stronger page like the en-US one may be the one that determines the ranking position, but in the re-ranking process they could swap the en-au page to be the one that is displayed in search results. But GSC would still show the wrong one.

我不會相信這裡的 GSC 資料。它們為了報表會把網址合併成一個。我認為是依據主要查詢時回傳的頁面，所以較強的頁面（例如 en-US）可能是決定排名位置的那個，但在重新排序的過程中，它們可能把 en-au 頁面換成搜尋結果裡顯示的那個。但 GSC 仍然會顯示錯的那個。

Check in some 3rd party tooling to see which was actually shown for SERPs in the country over time before you decide to do this. You might be surprised to learn that the right pages are actually being shown.

在決定這麼做之前，先用一些第三方工具查查，隨著時間，在該國的 SERP 實際顯示的是哪個頁面。你可能會驚訝地發現，其實顯示的頁面是對的。

With that said, I'm also a fan of what I've always called the language-first approach. 1 page per language. Fewer, stronger pages. It solves a lot of issues and headaches around internationalization and you can still use dynamic personalization for things that might be different in the countries, or list both, etc.

話雖如此，我也很喜歡我一直稱為「語言優先」的做法。一個語言一頁。頁面更少、更強。它解決了很多關於國際化的問題和麻煩，而且各國可能不同的東西，你還是可以用動態個人化，或兩種都列出。

It's merged. The announcement mentioned the API also: https://developers.google.com/search/blog/2019/02/consolidating-your-website-traffic-on

是合併過的。那則公告也有提到 API：https://developers.google.com/search/blog/2019/02/consolidating-your-website-traffic-on

IP tables are notoriously bad, especially in small areas like the border of Germany and Switzerland for instance. The popup is helpful, but one page per language is more fool-proof imo.

IP 對照表出了名地差，特別是在小區域，例如德國和瑞士的邊境。彈出視窗有幫助，但我認為一個語言一頁更萬無一失。

As for the feeds, some support multiple currencies, others you could always use a parameter with # to change the currency shown on the page, but this would still be 1 URL.

至於 feed，有些支援多幣別，其他的你可以用帶 # 的參數來改變頁面上顯示的幣別，但這仍然是同一個網址。

Yeah, for same language duplicates at least.

對，至少對相同語言的重複頁面是這樣。

I'm the technical SEO who usually solves the major issues and then goes and works on your content. There's only so much to actually do for technical SEO that matters. I don't tend to stay in the tech SEO lane, because it's often not what is best for the business and at the end of the day, that is what matters.

我是那個通常先解決主要問題、然後去處理你的內容的技術 SEO。真正重要的技術 SEO 其實能做的事有限。我不太會停留在技術 SEO 的賽道，因為那往往不是對企業最好的事，而說到底，那才是重點。

If you go look at for instance the Learn / Topic Hub at IBM, I was part of that project and it's predecessor to kick off ranking for non-branded things for the first time. Also, the IBM clear board videos on YouTube. At Ahrefs, many of the programmatic content and tools were my projects.

舉例來說，你可以看看 IBM 的 Learn／Topic Hub，我參與了那個專案和它的前身，讓 IBM 第一次開始針對非品牌關鍵字排名。還有 YouTube 上 IBM 的 Clearboard 影片。在 Ahrefs，許多程式化內容和工具也是我的專案。

And yep, many CMSs like WordPress usually aren't going to have major problems. But with enterprise, there's a lot of custom stuff, JavaScript, hacked together things, etc where the issues justify a role like a technical SEO.

沒錯，像 WordPress 這類 CMS 通常不會有重大問題。但企業級網站有很多客製化的東西、JavaScript、東拼西湊的東西等等，這些問題才足以讓技術 SEO 這種職位有存在的理由。

As far as why limit myself, I don't feel like I ever did. In fact I've been largely product side for many years now coming up with new features and processes and all. If you look at any of my early writing back on SEL though, I had articles for local, paid, link building, content, etc. I had the articles of the year on SEL for link building in 2015 and for paid search and SEO in 2016.

至於為什麼限縮自己，我覺得我從來沒有這樣。事實上這些年我大多在產品端，想新功能、新流程之類的。不過如果你看我在 SEL 的早期文章，我寫過在地、付費、連結建設、內容等等。我在 2015 年拿過 SEL 連結建設的年度文章，2016 年拿過付費搜尋與 SEO 的年度文章。

The branding is because being good at one thing means people go to you for that one thing and I happen to like audits and weird issues that others struggle to troubleshoot. It's also easier to be known for that thing than to try to go up against generalists like the Neil Patels or Rand Fishkins of the world. When I started speaking, I chose technical SEO to be that one thing because with my background, I had a lot to offer here and when trying to get speaking slots, there wasn't that much competition. u/paulshapiro was probably the biggest name for this at the time. I still have a goal to go over people's heads and show them something they've never seen before with every presentation, and that's kind of hard to do with more general talks.

品牌定位是因為，專精一件事，人們就會為了那件事找你，而我剛好喜歡稽核和別人難以排除的怪問題。比起去跟 Neil Patel 或 Rand Fishkin 那樣的通才競爭，被認識成專精某件事也比較容易。我剛開始演講時選技術 SEO 當那件事，因為以我的背景，這方面我能提供很多，而且當時爭取講者名額時，這塊的競爭不多，u/paulshapiro 大概是當時這個領域最有名的人。我現在還是有個目標：每場演講都要超出大家的認知，讓他們看到從沒見過的東西，而這在比較籠統的主題上很難做到。

You don't need this. You need a solid understanding of the basics. It's boring, but doing the basics well is what will drive success in most cases. That and a good work ethic are what will get you hired.

你不需要這個。你需要的是對基礎有紮實的理解。這很無聊，但把基礎做好，才是多數情況下成功的關鍵。這個加上良好的工作態度，才會讓你被錄用。

Go read Google documentation: https://developers.google.com/search/docs The number of people in SEO who have never read these always surprises me.

去讀 Google 的文件：https://developers.google.com/search/docs 。SEO 圈裡有多少人從來沒讀過這些文件，總是讓我很驚訝。

If you want to keep up with changes, seroundtable. I'm a big fan of the Ahrefs blog as well.

如果你想跟上變化，看 seroundtable。我也很喜歡 Ahrefs 的部落格。

I mean I was in-house at Ahrefs, but it was a SaaS so a bit different. I assume you mean for an enterprise? It would have to be some combination of fun / interesting and very well compensated for me to consider it.

我的意思是，我在 Ahrefs 就是企業內部，不過那是 SaaS，有點不同。我猜你指的是一般企業？要讓我考慮的話，得同時有趣好玩，而且薪水非常優渥。

In-house Pros:
-Steady paycheck
-Health insurance and other benefits
-Lots of opportunities to go deep and really think about impact

企業內部優點：
- 穩定的薪水
- 健保與其他福利
- 有很多機會可以深入、認真思考影響

In-house Cons:
-Politics
-Things can move slowly
-Too many meetings

企業內部缺點：
- 政治
- 事情可能進展很慢
- 會議太多

Independent contractor pros:
-More free time
-Higher hourly rate
-Freedom to choose who I work with (this is a privilege, and not everyone will be in this position. I wasn't when I did contracting work over a decade ago, and it's much better now)
-More variety

獨立接案優點：
- 更多自由時間
- 更高的時薪
- 可以自由選擇合作對象（這是種特權，不是每個人都有這個條件。十幾年前我做接案時就沒有，現在好多了）
- 更多變化

Independent contractor cons:
-Taxes and other additional costs like health insurance
-Having to do sales
-Having to do paperwork / contracts
-More unpredictable as far as leads / work
-No paid leave
-Having to chase people for money

獨立接案缺點：
- 稅和其他額外成本，例如健保
- 必須做業務
- 必須處理文書與合約
- 案源和工作比較不可預測
- 沒有帶薪假
- 必須追著人討錢

Just have an agent do it. =)

叫 agent 去做就好。=)

Just give your dot, grokbot, muse, hermes agent, etc access to things and check every day / week, setup a followup cadence, etc. Whatever kind of process you want for it, or even just send you a daily reminder of ones you need to do. Or have your agent create/send the drafts for the followups if you want. It's kind of crazy that all you have to really do is ask for this kind of thing now.

就是讓你的 dot、grokbot、muse、hermes agent 之類的，取得相關資料的存取權，每天或每週檢查、設定後續追蹤的節奏等等。你想要什麼樣的流程都可以，甚至只是每天提醒你哪幾筆需要處理。或者，如果你想，也可以讓你的 agent 建立並寄出追蹤的草稿。現在你真的只要開口要求這類事情，這有點瘋狂。

You need champions. People who can play the politics, who can work with other teams to package up initiatives, who can get the buy-in needed for big dreams and to change the way things are done.

你需要推手（champions）。這些人懂得處理政治，能和其他團隊合作把方案包裝起來，能取得所需的認同，去實現大夢想、改變做事的方式。

The reality is SEO by itself doesn't get very far, but if you can show the larger picture and end up packaging as many things together as possible and show why that's good for the company and each team, then you will be able to get things through.

現實是，SEO 單靠自己走不了多遠，但如果你能呈現更大的圖像，盡量把更多事情包在一起，並說明這對公司和每個團隊有什麼好處，你就能讓事情通過。

This kind of project will also help people get promoted, and generally the higher you go in an organization the easier things get because you have more control and answer to less people.

這種專案也會幫助人升遷，而且通常在組織裡位置越高，事情越容易，因為你擁有更多掌控權，需要對更少的人負責。

Yeah, I mean it's on everyone's mind these days.

是啊，我的意思是，這是現在大家心裡都在想的事。

Not that I can think of. I just normally try to describe things simply. If I have to use an analogy, it's because I can't explain something well enough or an editor might have asked me to add one, which probably means I didn't simplify and explain it well enough.

我想不到有。我通常就是試著把事情簡單描述。如果我必須用類比，那是因為我沒能解釋得夠好，或者編輯要求我加一個，這大概代表我沒有把事情簡化、解釋清楚。

According to AI Mode:

根據 AI Mode：

"The sky is blue because of a phenomenon called Rayleigh scattering, which occurs when sunlight is scattered by the gases in Earth's atmosphere. [1]

「天空是藍色的，因為一種叫做瑞利散射（Rayleigh scattering）的現象，當陽光被地球大氣層中的氣體散射時會發生。[1]

Here is exactly how it works:

確切的原理是這樣：

Sunlight is Made of All Colors: Although light from the sun looks white, it is actually a combination of all the colors of the rainbow. [1]

陽光由所有顏色組成：雖然太陽光看起來是白色的，其實是彩虹所有顏色的組合。[1]

Light Travels in Waves: Each color has a different wavelength. Red and orange light have long, lazy wavelengths, while blue and violet light have short, choppy wavelengths. [1, 2]

光以波的形式傳播：每種顏色有不同的波長。紅光和橙光有長而慵懶的波長，藍光和紫光則有短而急促的波長。[1, 2]

The Atmosphere Acts as a Filter: When sunlight enters the atmosphere, it hits gas molecules (mostly nitrogen and oxygen). Because blue light has short, small waves, it crashes into these tiny molecules and scatters in all directions much more easily than the other colors. When you look up, you are seeing this scattered blue light. [1, 2, 3, 4]"

大氣層像一個濾鏡：陽光進入大氣層時，會撞上氣體分子（主要是氮和氧）。因為藍光的波短而小，撞上這些微小分子時，會比其他顏色更容易向四面八方散射。當你抬頭看，看到的就是被散射的藍光。[1, 2, 3, 4]」

Hey, thanks for watching and I appreciate the support! Ryan Law is well loved for a good reason though. I didn't mind losing to him. I knew my approach was a risk when I start talking about processes and APIs vs just a feature in the tool though. It goes over many people, but I like to show what is possible and something people likely haven't seen or heard before.

嘿，謝謝你的收看，也感謝你的支持！不過 Ryan Law 受大家喜愛是有原因的，我輸給他也不介意。我知道當我開始談流程和 API，而不只是工具裡的一個功能時，我的做法是有風險的。這會讓很多人聽不懂，但我喜歡展示有什麼可能，以及人們可能沒看過、沒聽過的東西。

As for the website, I'm trying to rank for oh so many things. It's going pretty well so far and getting a lot of traffic considering the page went from one page to thousands just a few months ago.

至於網站，我想排名的東西多到數不清。目前進展不錯，考慮到網站幾個月前才從一頁變成幾千頁，已經帶來很多流量。