Cách Mình Phát Triển SEO Publishing Agent

Từ n8n workflows đến AI agent tự động publish SEO content lên WordPress

Publish bài SEO lên WordPress không đơn giản. Agency chạy chục dự án cùng lúc, mỗi client 1 WordPress site khác nhau, mỗi site 1 cấu trúc HTML riêng -- và đó chính là bottleneck lớn nhất pipeline content.

Tool: agentic-publish.seongonai.com
Codebase: github.com/seongon-agency/agent-seo-posting-railway

1. Tổng Quan

SEO Publishing Agent làm 2 việc tách biệt:

Setup dự án (1 lần): Agent scan input HTML (từ Google Docs) và target HTML (native format của CMS client), rồi tạo regex patterns để transform giữa 2 dạng. Patterns này lưu vào project settings.
Publish bài (mỗi bài): Nhận link Google Docs, tải HTML, clean, xử lý hình ảnh, áp dụng HTML patterns đã lưu để transform content, rồi publish.

Tùy dự án mà publish lên site nội bộ (khi client không cho kết nối API) hoặc thẳng lên site client (khi được cấp quyền). Chi tiết về WordPress REST API integration xem tại bài Tích Hợp WordPress.

Layer	Công nghệ
Frontend	Next.js 15, React 19, Tailwind CSS, Shadcn UI
Backend	Next.js API Routes
Database	Supabase PostgreSQL
AI	Claude API (HTML pattern generation)
Integration	WordPress REST API, Google Docs (public HTML)

2. Hành Trình Phát Triển

Không phải mình ngồi xuống thiết kế agent từ đầu. Agent này là kết quả của 3 lần va vào tường rồi phải tìm cách khác.

2.1 Từ n8n Workflow Đến Internal Site

Cách tiếp cận đầu tiên: workflow n8n nhận link Google Docs, tải content về, format HTML theo template cố định, upload ảnh rồi gọi WordPress REST API để tạo post. Hoạt động -- nhưng yêu cầu client cấp WordPress credentials (username + application password). Nhiều client không cho.

Giải pháp: dựng WordPress site nội bộ cho mỗi dự án, agency kiểm soát hoàn toàn API access. Content team publish lên site nội bộ rồi copy sang site client.

Va vào tường: Mỗi dự án yêu cầu HTML format khác nhau. Dự án A cần <h2>, dự án B cần <h2 style="text-align: justify">, dự án C cần <h2 class="entry-title">. 1 workflow, 1 HTML template cố định -- không scale được.

2.2 HTML Config Per Project

Giải pháp: tạo HTML config riêng cho từng dự án. Quy trình onboard client mới -- AI team phải:

Xin technical SEO team 1 bài Google Docs content mẫu → tải về dạng HTML (input HTML)
Lấy HTML từ 1 bài đã publish trên CMS client (target HTML)
So sánh input HTML và target HTML bằng mắt, viết rules transform thủ công trong code node của n8n
Lặp lại cho h2, h3, p, img, ul, ol, table -- mỗi element type 1 rule

Input HTML (Google Docs):     <h2>Tiêu đề</h2>
Target HTML (Client CMS):     <h2 style="text-align: justify">Tiêu đề</h2>

→ AI team viết tay trong n8n code node:
  html = html.replace(/<h2>(.*?)<\/h2>/g, '<h2 style="text-align: justify">$1</h2>')

→ Lặp lại cho p, img, ul, ol, ... tất cả thủ công

Bài publish ra đúng format, nhưng mỗi client mới = tạo workflow mới, viết HTML transform rules từ đầu. Client đổi theme = rules hỏng, phải viết lại. 10 client = 10 workflows phải bảo trì.

2.3 Tại Sao Workflow Không Đủ

3 giai đoạn trên có chung 1 pattern: mỗi lần giải quyết 1 vấn đề, công việc thủ công không mất đi mà chuyển sang chỗ khác.

Giai đoạn	Giải quyết được	Công việc thủ công mới
Workflow trực tiếp	Tự động publish	Phải xin API access từ client -- không kiểm soát được
Internal site	Không cần API client	Mỗi client cần 1 workflow riêng với HTML config riêng
HTML config per project	Format đúng cho từng site	Tạo + bảo trì workflow riêng cho mỗi client, sửa lại khi site thay đổi

3. Từ n8n Đến Vibe Coding Agent

3.1 Bottleneck Thực Sự

Với n8n, mỗi lần nhận dự án mới, AI team phải làm 1 loạt việc thủ công: xin technical SEO team 1 bài Google Docs content mẫu cùng target HTML (HTML hiển thị đúng trên CMS client), rồi sửa code node trong n8n, cấu hình Google Sheets tab, thiết lập rules resize ảnh, rules đặt tên ảnh, và adapt toàn bộ workflow template theo đặc thù từng client.

Công việc này lặp lại y hệt cho mỗi dự án mới, nhưng chỉ AI team mới làm được vì chỉ AI team biết sửa n8n workflow. Technical SEO team -- những người hiểu rõ nhất yêu cầu của từng client -- phải chờ AI team setup xong mới bắt đầu publish.

Mục tiêu đầu tiên: tự động hóa quá trình adapt workflow cho từng client, rồi chuyển giao việc đó cho technical SEO team. AI team không còn phải setup từng dự án tay, giải phóng thời gian cho development.

3.2 Từ Automation Đến Webapp

Tự động hóa quá trình setup chỉ giải quyết 1 nửa. Nửa còn lại: technical SEO team cần 1 nơi để thực hiện việc đó -- 1 giao diện mà ai cũng truy cập được, không cần biết n8n, không cần AI team hướng dẫn.

n8n không đáp ứng được cả 2 nhu cầu này. n8n tốt cho việc nối các bước xử lý lại với nhau, nhưng không phải nền tảng để build 1 product với UI riêng, project management, user accounts, và quy trình setup tự động bằng AI. Cái mình cần là 1 webapp.

3.3 Vibe Coding Như Một Lựa Chọn

Quyết định build webapp đặt ra câu hỏi tiếp theo: build bằng cách nào? Team không có developer chuyên viết code production. Nhưng team có thứ quan trọng hơn -- kinh nghiệm vận hành. Hàng trăm lần sửa n8n workflow, hàng trăm lần adapt HTML config, hàng trăm lần xử lý ảnh cho từng client. Hiểu bài toán đến từng chi tiết nhỏ nhất.

Vibe coding -- mô tả yêu cầu cho AI, để AI sinh code, rồi iterate -- cho phép biến kinh nghiệm vận hành đó thành phần mềm thực. Mỗi phần của agent được build từ việc mô tả lại chính xác những gì mình đã làm tay trên n8n:

Việc làm tay trên n8n	Mô tả cho AI để build
Sửa code node xử lý Google Docs HTML	Service tải HTML, convert CSS sang inline styles, clean thừa spans
Cấu hình rules resize + đặt tên ảnh	Service xử lý ảnh với config per project
Adapt HTML template cho từng client	AI scan input/target HTML, tự sinh regex patterns
Quản lý credentials từng site	Project settings với encryption, UI để team tự nhập

Vibe coding giải quyết cùng lúc 2 việc: xóa bottleneck vận hành (technical SEO team tự setup và publish) và nâng cao năng lực team (từ chỉ biết dùng n8n sang build được webapp với AI).

3 giai đoạn workflow trước đó là giai đoạn học domain. Không có n8n, không hiểu đủ sâu để mô tả yêu cầu cho AI khi vibe coding. Workflow thất bại ở scale, nhưng thành công ở việc dạy team hiểu bài toán.

4. Vấn Đề Cốt Lõi

4.1 Loại Bỏ Phụ Thuộc Google APIs

Làm việc với Google APIs trong n8n là nguồn lỗi liên tục: rate limits, yêu cầu reauthorization thường xuyên, Google thay đổi API không báo trước. Mỗi lần authorization hết hạn, workflow dừng và phải có người vào n8n reconnect tay. Không ổn định cho production.

Agent loại bỏ hoàn toàn Google APIs bằng cách thay thế từng điểm phụ thuộc:

Trước (n8n + Google APIs)	Sau (Agent)	Lý do
Gọi Google Docs API để lấy HTML content	Gửi GET request đến URL `/pub` của Google Docs	Link `/pub` là published version, trả HTML trực tiếp -- không cần authentication, không rate limit
Google Sheets API để quản lý danh sách bài, config	Project configuration + sheet interface trong webapp	Mỗi project lưu config riêng, danh sách bài nhập trực tiếp trên giao diện publish
Tạo + update Google Docs qua API để lưu HTML đã xử lý	Tạo draft post trên internal WordPress site	Mục đích chỉ là lưu HTML ở đâu đó -- WordPress REST API ổn định hơn, mình kiểm soát hoàn toàn

Kết quả: 0 Google API calls trong toàn bộ pipeline. Không còn authorization issues, không rate limits, không bị break khi Google thay đổi API.

4.2 Tạo Abstraction Cho Các Rules Lặp Lại

Mỗi dự án có yêu cầu khác nhau về cách xử lý ảnh: resize bao nhiêu, đặt tên theo kiểu gì, format nào, ảnh có caption [caption],... hay không. Trên n8n, mỗi yêu cầu kiểu này là 1 code node phải sửa tay. Không thể giao cho technical SEO team tự làm.

Giải pháp: tạo abstraction cho từng loại rule, biến thành options trên giao diện mà non-tech users có thể tự chọn.

Resize method -- cách xử lý kích thước ảnh:

Option	Hành vi
`fixed_width`	Resize về target width (ví dụ 800px), giữ nguyên tỷ lệ gốc. Dùng khi site client có max content width cố định
`google_docs_original`	Giữ nguyên kích thước mà Google Docs export. Dùng khi content team đã resize ảnh trong Docs
`no_resize`	Copy ảnh nguyên bản, không re-encode. Dùng khi ảnh đã tối ưu sẵn hoặc client muốn giữ chất lượng gốc

Naming method -- cách đặt tên file ảnh:

Option	Hành vi
`default`	Đặt tên tuần tự: `image_1.jpg`, `image_2.jpg`. Đơn giản, không phụ thuộc content
`alt_text`	Lấy alt text của ảnh làm tên file. Tốt cho SEO khi alt text đã được viết chuẩn
`main_keyword`	Lấy main keyword của bài + index làm tên file. Tốt cho SEO khi muốn ảnh chứa keyword chính

Image format và quality:

Setting	Options
Format	JPEG, PNG, WebP
Quality	1-100 (default: 92)

Technical SEO team chọn options khi setup dự án, agent tự áp dụng cho mọi bài publish sau đó. Không cần hiểu code, không cần AI team can thiệp.

4.3 HTML Patterns

Đây là bài toán tốn thời gian nhất khi onboard client mới trên n8n: phân tích sự khác biệt giữa HTML output từ Google Docs và HTML mà CMS client cần, rồi viết rules transform thủ công.

Ví dụ cùng 1 đoạn content:

<!-- Input HTML (Google Docs export) -->
<h2>Tiêu đề</h2>
<p>Nội dung đoạn văn</p>

<!-- Target HTML (CMS client cần) -->
<h2 style="text-align: justify">Tiêu đề</h2>
<p class="content-text" style="text-align: justify">Nội dung đoạn văn</p>

Trên n8n, mình phải nhìn 2 dạng HTML, tự hiểu cần thêm gì, rồi viết code transform. Lặp lại cho h2, h3, p, img, ul, ol, table -- mỗi element type 1 rule. Mỗi client mới = viết lại từ đầu.

Agent dùng Claude để tự động hóa việc này. Khi setup dự án, technical SEO team đưa vào input HTML và target HTML, AI scan cả 2 rồi sinh mảng regex patterns:

{
  "element_type": "h2",
  "source_pattern": "<h2>(.*?)</h2>",
  "target_pattern": "<h2 style=\"text-align: justify\">\\1</h2>"
}

AI lặp lại cho tất cả element types -- tự động, không cần viết rules tay. Patterns lưu vào project settings, áp dụng tuần tự khi publish. Khi client đổi theme, chỉ cần re-scan với target HTML mới.

Hạn chế: Input HTML không phải lúc nào cũng nhất quán. Cùng 1 bài mà chỗ có dir="ltr" chỗ không, chỗ có extra attributes chỗ không. AI scan HTML kiểu này sẽ sinh patterns không nhất quán. Cách xử lý: dùng chức năng AI Modify để sửa patterns sau khi scan, hoặc clean input HTML trước khi đưa vào.

5. Những Bài Học

Workflow là giai đoạn học domain. 3 giai đoạn n8n thất bại ở scale, nhưng thành công ở việc dạy team hiểu bài toán đủ sâu để mô tả yêu cầu cho AI. Không có n8n, không có agent.

Loại bỏ dependency không kiểm soát được. Google APIs, client credentials -- mỗi dependency bên ngoài là 1 điểm chết tiềm tàng. Thay thế bằng thứ mình kiểm soát hoàn toàn (public URL, internal WordPress site) ổn định hơn nhiều.

Biến rules thành UI options. Code node trong n8n chỉ AI team sửa được. Abstraction thành dropdown options trên giao diện thì technical SEO team tự làm. Bottleneck biến mất.

Vibe coding chỉ là bước cuối. Mô tả yêu cầu cho AI chỉ hiệu quả khi mình thực sự hiểu bài toán. Kinh nghiệm vận hành thực tế là input quan trọng nhất, không phải kỹ năng code.