感應手機的那一刻，對方螢幕跳出一個網頁，畫面卻只有一張大頭照跟幾個社群圖示，找不到「儲存聯絡人」的按鈕，對方划了幾下就把分頁關掉，這張名片交換等於什麼都沒發生。
很多人以為問題出在那張卡片不夠精緻，換一張金屬卡、換一顆貼紙，對方就會記住你。其實真正決定這次交換有沒有留下痕跡的，是被觸發打開的那個網頁，也就是 NFC 電子名片頁面本身：感應或掃碼只是啟動的動作，對方看到的內容、能不能一鍵存進通訊錄、找不找得到你的社群或作品，全部由這個網頁決定。網頁沒做好，再貴的卡片也只是白感應一次。
這也是為什麼實體卡該不該買、買哪一種可以先放一邊，先把網頁做起來，之後要不要加購一張感應卡，只是把這個網址寫進卡片裡的最後一步。
NFC 電子名片，真正決定體驗的是背後那個網頁
把「卡片」跟「網頁」這兩件事分開來看，會清楚很多。NFC 標籤、貼紙、感應卡，做的事情就只有一個，靠近手機時觸發一個動作，通常是打開一個網址；QR Code 也是同樣的角色，掃描之後一樣是導向那個網址。真正被對方看到、決定第一印象好不好的，從頭到尾都是那個網頁，不是卡片本身的材質或造型。
這也是為什麼不需要先買一張夠炫的實體卡才能開始，網頁才是主體，先把它做起來，之後要不要加購 NFC 感應卡，只是把這個網址寫進標籤裡這一個步驟。
這裡也順便把讀者容易搞混的 NameDrop 拉出來釐清。蘋果官方支援文件說明，NameDrop 是把 iPhone 螢幕靠近另一支 iPhone 或 Apple Watch（限 Apple Watch Ultra、Series 7 以後機型、SE 第二代以後），兩邊裝置都顯示畫面後，選擇要分享的聯絡人欄位再點一下儲存，走的是裝置對裝置的 AirDrop 傳輸，完全不經過網頁。文件也特別註記，NameDrop 僅適用於傳送新的聯絡資訊，不能拿來更新對方通訊錄裡既有的聯絡人，而且這項功能預設是開啟的，要關閉得到「設定」>「一般」> AirDrop 裡把「將裝置互相靠近」關掉。這跟本篇要做的 NFC 電子名片頁面是兩件事：一個是 iPhone 之間互相靠近就能交換聯絡人卡片，另一個是感應或掃碼打開一個你自己架設、可以自訂內容的網頁，不要把兩者混為一談。
單頁式資訊架構，姓名職稱要比社群連結搶眼
決定這個網頁該放什麼，是動工的第一步。核心原則很單純：單頁、由上而下捲動，不做多層選單，也不拆成好幾個子頁面，讓對方滑一頁就看完。內容大致分成三層：第一層是身分識別，姓名、職稱、所屬公司或品牌，通常搭配一張大頭照或品牌識別圖；第二層是核心行動，儲存聯絡人按鈕、電話與 Email 的直接觸發連結、加 LINE 或社群私訊入口；第三層才是次要資訊，社群帳號、Google 商家檔案連結、作品集或服務頁連結。
如果差異化的切角是「在既有網站底下加開一個子頁面」，網址可以直接掛在本尊網站的網域下，例如公司官網加一個/card/wang-xiaoming這樣的路徑，視覺上沿用同一套字體與配色。對方點進來會覺得跟本站是同一家，不必另外租網域，也不必為了這一頁另外設計一套風格。
姓名、職稱與所屬公司放在最上層
行動裝置螢幕窄，讀者是由上而下捲動的，第一屏如果沒有交代清楚「這是誰」，後面的按鈕再顯眼也沒人會按。姓名建議用整頁最大的字級，職稱與所屬公司用比姓名小一號的字級接在下面，讓視覺順序先確認身分，再往下看要做什麼。
搭配一張清晰的大頭照或品牌識別圖，可以再強化辨識速度，對方感應後的前一兩秒，眼睛掃過去就該認出這是剛才遞名片給他的人，而不是還要先讀完一段文字才確定。姓名、職稱、公司這三個欄位，也是後面結構化資料標記與 vCard 檔案都會重複用到的同一批資料，先在這裡定案，後面直接沿用即可。
聯絡方式與儲存按鈕是頁面的核心行動
這一區要放的是電話、Email、加 LINE 或社群私訊入口，再加上最重要的「儲存聯絡人」按鈕，背後就是後面會講到的那份 vCard 檔案。電話建議用可以直接點擊撥號的連結，Email 也做成點下去就開啟郵件的連結，讓對方不用手動輸入或複製貼上。
這幾個按鈕的視覺份量要拉開，用明顯的對比色或按鈕樣式凸顯，不要跟其他一般連結長得一樣。如果整頁的連結都用同一種灰色文字排列，對方很容易漏掉真正該點的那一個，滑過去就直接跳到社群連結區，回頭再找往往就懶得找了。
社群帳號和作品連結退到次要位置
社群連結像 Instagram、Facebook、YouTube，加上作品集或服務頁連結、Google 商家檔案連結，都放在頁面偏下方，用簡單的圖示列或清單呈現即可。這一批連結是認識你之後想多了解的內容，不是對方一進頁面就該優先看到的東西。
視覺上也不要跟儲存聯絡人按鈕搶重量，尺寸小一點、顏色低調一點都可以。把最重要的行動留在上面、把延伸內容擺在下面，讀者才不會在還沒存到聯絡人之前，就先被一排社群圖示分散了注意力。
存入聯絡人的按鈕，背後其實是一個 vCard 檔案
「儲存聯絡人」這顆按鈕看起來像是某種複雜功能，拆開來看其實很單純，它連到一個.vcf檔案，副檔名代表 vCard（Virtual Contact File），是 IETF 制定、目前 iOS、Android、Windows、macOS 都通用的聯絡人交換格式。按鈕本身只是一個指向這個檔案的超連結，瀏覽器接到.vcf檔就會提示下載，或直接詢問要不要加入通訊錄。
IETF 的 RFC 6350 明確定義了 vCard 4.0 的正式規格：一個 vCard 物件以BEGIN:VCARD開始、END:VCARD結束，VERSION必須緊接在BEGIN:VCARD之後，而且整份規格只強制要求VERSION跟FN（姓名的完整顯示文字）兩個屬性一定要有。其餘像 N（結構化姓名）、ORG（所屬公司或單位）、TITLE（職稱）、TEL（電話）、EMAIL（Email）、URL（網址）、PHOTO（照片）、NOTE（備註）都是選填但常用的欄位，字元編碼一律用 UTF-8，值裡出現逗號、分號、反斜線或換行都要用反斜線轉義。
vCard 裡固定寫入的姓名、職稱、電話與網址
實作時真正要準備的欄位，跟前面資訊架構那節蒐集到的資料是同一批：姓名對應 FN，結構化的姓名拆分對應 N，所屬公司對應 ORG，職稱對應 TITLE，電話對應 TEL，Email 對應 EMAIL，網址對應 URL。這些屬性名稱是 RFC 6350 裡固定的寫法，不能自己改名稱，只能照格式填值。
準備這份檔案不需要另外的程式邏輯，只要照這套屬性名稱把資料一行一行寫進純文字檔就完成，任何文字編輯器都能開啟檢查。前面單頁式架構裡蒐集到的姓名、職稱、公司這幾個欄位，拿來這裡直接對應填入即可，不需要重新想一次要放什麼內容。
檔案版本不同，舊手機讀取的相容性也不同
vCard 從 1996 年由蘋果、AT&T、IBM、西門子組成的 Versit Consortium 制定 2.1 版開始，字元編碼支援有限；1998 年的 3.0 版（RFC 2426）補上 NICKNAME、CATEGORIES、GEO 等欄位，並支援用 base64 格式內嵌照片，是至今許多應用程式為求最大相容性仍預設匯出的版本；到了 2011 年的 4.0 版（RFC 6350），才強制要求 UTF-8 編碼，解決了國際字元容易變亂碼的老問題。
問題是目前應用程式對 4.0 版新增欄位的支援落差仍然存在，比較舊的通訊錄程式不一定讀得完整。實務上常見的做法，是用 3.0 版的基本欄位組合，FN、N、TEL、EMAIL、ORG、URL，換取最廣的裝置相容性，而不是硬上最新的 4.0 版本。
下載鍵背後其實只是一個檔案連結
實作上最簡單的做法，是把準備好的.vcf檔案放在網站伺服器上，「儲存聯絡人」按鈕只是一個指向這個檔案的超連結。瀏覽器接到.vcf檔之後，會依裝置類型提示下載，或直接詢問要不要加入通訊錄，不需要額外寫任何後端程式。
這也呼應前面提到的，vCard 本質上是一份 plain text 格式的檔案，任何文字編輯器都能開啟。真的要維護，直接改這個檔案裡的內容重新上傳就好，不需要碰到頁面其他部分的程式碼。
NFC 標籤與 QR Code 背後只藏了一個網址
不管是 NFC 標籤還是 QR Code，最常見也最推薦的做法，都是讓它們只儲存一個網址，手機讀到之後自動開啟瀏覽器，導向前面幾節建置好的那個網頁。這樣安排的好處很直接，頁面內容以後要改，不必重新寫入標籤或換掉印好的 QR Code，維護只發生在網頁端這一邊。
底層在做的事情，Android 官方開發者文件裡有清楚說明。一張 NFC 標籤裡的資料以「NDEF 訊息」封裝，一則 NDEF 訊息可以包含一筆或多筆「NDEF 記錄」，其中「Well Known」類型搭配 RTD_URI 就是最常見的「URL 記錄」，開發上可以直接用NdefRecord.createUri(uri)這個輔助方法建立，不需要手動組二進位資料。就算自己不寫程式，市面上的 NFC 寫入 App 或線上 QR Code 產生器要填的東西，本質上就是這一個網址。
QR Code 本身是國際標準 ISO/IEC 18004（2000 年通過為國際標準，日本 JIS X 0510 早在 1999 年就先通過），內建 4 種糾錯等級，由低到高分別是 L、M、Q、H，依 QR Code 標準制定者 Denso Wave 的官方說明，最高等級 H 即使碼有約 30%毀損仍可被正確讀取。這也是為什麼 QR Code 可以印在名片、貼紙這種容易磨損的載體上，還能穩定掃出來的原因。
手機讀到標籤通常直接跳出預覽，新版 Android 需先點通知
感應或掃碼後，手機直接彈出網址預覽，或直接開啟瀏覽器，不需要另外開任何 App，這是 URL 記錄類型的標準行為。對方看到的體驗，基本上跟點一個連結沒有兩樣，只是觸發的動作換成靠近或掃描。
不過這裡有個近年的技術變化值得留意。Android 官方文件提到，從 Android 16 開始，手機掃到儲存網址的 NFC 標籤，會直接觸發開啟連結的ACTION_VIEW，而不是過去的ACTION_NDEF_DISCOVERED；從 Android 17 開始，掃到這類標籤會先跳出一則「開啟連結」的通知，需要使用者明確點一下才會真的打開瀏覽器，多一層確認的用意是防止惡意標籤被動觸發開網頁。也就是說，比較新版本的 Android 手機，對方感應之後可能還要多點一下通知才會看到頁面，這跟 iPhone 感應後直接跳出網頁預覽的體驗略有差異。
金屬卡面或加厚手機殼容易讓感應距離變短
NFC 是近距離無線感應技術，原本的感應距離就只有幾公分，這是硬體層面的物理特性，不是網頁做得好不好的問題。金屬材質的卡面或過厚的手機殼，容易讓天線訊號被遮蔽或衰減，導致感應變得不穩定，對方要多靠近幾次或換個角度才感應得到。
遇到感應不到的狀況，先請對方拿掉手機殼，或把卡片換個角度再試一次，通常就能解決。這一點跟前面講的網頁內容、頁面速度都無關，單純是 NFC 天線與金屬、厚殼之間的物理限制，先知道這個限制，才不會誤以為是網頁或標籤本身出了問題。
電子名片頁面要跟 Google 商家檔案雙向連結
如果讀者或所屬公司已經有 Google 商家檔案，這個網頁應該跟商家檔案雙向串接，而不是各自獨立存在。一邊是商家檔案的「網站」欄位直接填回這個網頁的網址，另一邊是這個網頁本身放一個連回 Google 商家檔案的連結，方便對方順手留評論、查地址或看營業時間。
這樣安排的好處是，不管對方從哪個入口先進來，都能找到另一邊，也讓這個子頁面多一個被搜尋到的機會。Google 官方支援文件對編輯商家檔案的流程說明得很清楚，作法是登入與商家檔案連結的 Google 帳號，進入商家檔案後選擇「編輯設定檔」，在聯絡資訊分頁點擊「網站」欄位旁的編輯圖示，輸入完整網址(須包含https://)後儲存，文件也提醒異動送出後可能需要一段時間才會顯示在檔案上。
頁面上該放一個連回 Google 商家檔案的連結
具體做法是在網頁的次要資訊區塊，放一個明確標示「Google 評價」或「地圖」字樣的連結，指到自己的 Google 商家檔案頁面。對方看完你的介紹之後，順手點一下就能留下評論，或查一下地址跟營業時間，不用再回頭用搜尋去找。
這個連結放的位置，跟前面「社群帳號和作品連結退到次要位置」那節是同一批次要資訊，不需要另外開一個顯眼區塊，跟其他社群圖示排在一起就足夠。
Google 商家檔案的網站欄位，要填回這一頁的網址
反過來那一邊的設定，是進入 Google 商家檔案的編輯畫面，在「網站」欄位貼上這個網頁的完整網址(含https://)並儲存。設定完成後，從 Google 搜尋或地圖進來查資料的人，也能點到這個網頁，不必只靠對方主動感應卡片才看得到。
兩邊互相指過去之後，這個網頁等於多了一個從商家檔案導流進來的入口，跟本來就在經營的搜尋曝光管道接上，而不是只靠當面遞卡片、掃碼才會被看到。
手機版面把儲存按鈕留在第一屏
版面與效能的原則，核心是兩件事。第一件事是單欄由上而下排列，不做多欄位或側邊欄，行動裝置螢幕本來就窄，多欄只會讓內容擠成一團，對方要左右滑動才看得完整反而更麻煩。
第二件事是載入速度要快，而且這一點的重要性，在 NFC 電子名片這個情境下特別明顯。這頁通常是在對方剛見面、當場感應打開的情況下被看到，如果載入要等上好幾秒，對方很可能等不及就把畫面關掉，前面辛苦規劃的資訊架構等於白做。Think with Google 的研究指出，行動網頁的載入時間從 1 秒增加到 10 秒，訪客跳出的機率會提高 123%，這項數據來自 Google 用深度神經網路分析大量跳出與轉換資料所得出的結果。放到當面感應打開這種即時情境來看，載入慢個幾秒，對方等不及直接關掉畫面的機率並不低。
實作上建議控制圖片大小，大頭照與品牌識別圖適度壓縮，避免載入不必要的外部腳本，讓「儲存聯絡人」這個核心按鈕能在第一屏就被看到，不必往下滑才找得到。對方通常只會等這麼幾秒，越快看到能點的按鈕，願意花時間存下聯絡人的機率就越高。
結構化資料標記，把身分交代給搜尋引擎
這個網頁除了給人看，也可以順手讓搜尋引擎看懂這是誰的頁面。做法是在頁面裡加入 schema.org 的 Person 結構化資料，用 JSON-LD 格式標記起來，把姓名、職稱、所屬公司、網址這些欄位交代清楚，讓 Google 有機會把這頁的身分資訊拿去用在搜尋結果的呈現上。
這一節屬於做完基本功能後可以加分的部分，不是非做不可，但成本很低，只要幾行標記碼，對於本來就想強化個人品牌搜尋能見度的讀者來說很划算。schema.org 官方文件列出 Person 型別常用的屬性，包括name（姓名）、jobTitle（職稱）、worksFor（所服務的組織）、telephone、email、url（人物網址），JSON-LD 則是把這些屬性寫進<script type="application/ld+json">區塊裡、不必混進顯示用 HTML 的標記語法，是目前主流採用的寫法。
姓名、職稱與所屬公司，標成人物身分的結構化資料
最基本的 Person 標記，要填的是name、jobTitle、worksFor、url這幾個屬性，對應到的正好是前面單頁式資訊架構裡蒐集到的姓名、職稱、公司、網址這一批資料，不用另外再準備一次。
寫法上就是一段 JSON-LD，放進頁面的<head>或內容裡都可以，瀏覽器不會顯示這段內容，只有搜尋引擎的爬蟲會讀取。填完這幾個欄位，這個網頁的身分資訊就有機會被 Google 拿去用在搜尋結果的呈現上，比單純的純文字內容多一層結構化的線索。
社群帳號串起來，搜尋引擎才認得是同一個人
sameAs是 schema.org 對這個屬性的官方定義，說明是明確指示該項身份的參考網頁網址，例如維基百科頁面，實務上也普遍用來把同一人的多個社群帳號網址串在一起。把 Instagram、Facebook、YouTube 等帳號的完整網址列進sameAs，等於明確告訴搜尋引擎這些帳號都是同一個人。
這批社群帳號連結，跟前面「社群連結退到次要位置」那節蒐集到的資料是同一批，直接拿來填進sameAs即可，不需要另外整理一份清單。做完這一步，搜尋引擎不只知道這頁屬於誰，還知道這個人在其他平台上的帳號是哪些。
上線前在 iPhone 與 Android 都要各測一次
上線前，拿一支 iPhone 跟一支 Android 手機，各自實際感應或掃碼一次，確認幾件事：連結能不能正常打開，儲存聯絡人按鈕點下去會不會跳出正確的通訊錄畫面，姓名與電話等欄位有沒有正確顯示，頁面在兩種手機的瀏覽器上排版有沒有跑掉。
這一步之所以必要，是因為 iOS 與 Android 對 NFC 標籤內容的處理行為並不完全一樣。前面提到，從 Android 17 開始，掃到儲存網址的 NFC 標籤會先跳出一則通知，需要使用者明確點一下才會真的打開瀏覽器，這跟 iPhone 感應後直接跳出網頁預覽的體驗不同。沒有雙平台各測一次，很可能其中一邊做出來的效果跟預期不同，等上線後才被對方發現，那時候要補救就麻煩多了。
資訊異動時只要改網頁，但存進手機的舊聯絡人不會跟著更新
網頁端做法相對於把資料直接寫死在 NFC 標籤或印出來的 QR Code 上，最大的優勢就在這裡：只要標籤或 QR Code 裡存的是網址，換工作、換電話、換職稱，都只需要改網頁內容，不必重新寫入標籤或換一張新卡片。前面規劃的資訊架構、vCard 欄位、結構化資料標記，全部沿用同一個網址，異動只發生在網頁這一端。
不過這裡要誠實點出一個格式本身的限制。對方如果已經把 vCard 檔案存進手機通訊錄，那份資料是當下下載的一份快照，之後網頁內容更新了，對方通訊錄裡舊的那筆聯絡人並不會跟著自動變動。這不是網頁做壞了，是 vCard 檔案格式本身的特性，下載下來的檔案是獨立的一份資料，不具備連線回源自動更新的機制，讀者需要知道網頁會更新、但已經存進對方手機的聯絡人不會這個差異，才不會誤以為改了網頁，全世界的人都會同步看到新資料。
名片遞出去之後會不會斷聯，關鍵從來不是卡片材質夠不夠高級，而是對方感應或掃碼之後，看到的那個網頁能不能在第一眼就交代清楚身分，再讓對方順手按下儲存聯絡人。這件事做到位，後續要不要加購一張感應卡、換一款貼紙，都只是把同一個網址寫進去的小事；沒做到位，再貴的卡片也只是讓對方多一次白感應的經驗。
換工作、換電話號碼是遲早會發生的事，把這些資訊放在網頁而不是寫死在卡片上，往後要更新就只是改一頁內容，不必重新印卡、重新寫標籤。這種可以隨時更新、也順手交代給搜尋引擎的做法，才是 NFC 電子名片真正值得投入的地方。