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

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 một WordPress site khác nhau, mỗi site một 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 hai việc tách biệt:

1. Setup dự án (một 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 hai dạng. Patterns này lưu vào project settings.
2. 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).

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 ba lần va vào tường rồi phải tìm cách khác.

2.1 n8n Workflow Trực Tiếp#

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.

Google Docs Link → n8n: Tải HTML → n8n: Format + Upload ảnh → WordPress REST API → Bài đăng (draft)

Workflow này làm đúng những gì agent hiện tại làm -- chỉ là mọi thứ cứng trong n8n nodes: HTML template cố định, image config cố định, WordPress credentials cố định cho một site.

Điều kiện tiên quyết: Client phải cho phép kết nối API vào WordPress site của họ. Cụ thể là cấp WordPress username + application password để workflow gọi REST API. Không có credentials này thì workflow không chạy được.

Va vào tường: Thực tế nhiều client không cho. Có client chỉ cấp tài khoản editor để đăng nhập tay trên WordPress admin, có client không muốn bất kỳ integration bên ngoài nào chạm vào site của họ. Workflow hoàn toàn phụ thuộc vào API access mà mình không kiểm soát được.

2.2 Workflow Publish Qua Internal Site#

Thay vì phụ thuộc API access của client, mình dựng các WordPress site nội bộ của agency -- mỗi dự án một site. Mình kiểm soát hoàn toàn API access, không cần xin phép ai.

Google Docs Link → n8n: Tải HTML → n8n: Format + Upload ảnh → Internal WordPress Site → Content team copy sang site client

Workflow này chỉ hoạt động với WordPress dạng Classic Editor. Các site dùng block editor (Gutenberg) thì HTML output khác hoàn toàn, workflow không xử lý được.

Giải quyết được: Vấn đề API access. Agency tự quản lý internal sites, không còn phụ thuộc client cấp credentials.

Va vào tường mới: Mỗi dự án yêu cầu HTML format khác nhau để hiển thị đúng trên site client. 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">. Cùng một workflow, cùng một HTML template cố định -- dẫn đến sự cấp thiết của việc chỉnh sửa mỗi project khi có dự án mới, tốn thời gian, nguồn lực.

2.3 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:

1. Xin technical SEO team một bài Google Docs content mẫu → tải về dạng HTML (input HTML)
2. Lấy HTML từ một bài đã publish trên CMS client (target HTML)
3. 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
4. Lặp lại cho h2, h3, p, img, ul, ol, table -- mỗi element type một 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

Giải quyết được: Bài publish ra đúng format cho từng site client.

Va vào tường nặng nhất: Mỗi client cần một workflow n8n riêng với HTML config riêng. Dự án mới = tạo workflow mới, viết HTML transform rules từ đầu. Mỗi khi client đổi theme = rules đó hỏng, phải viết lại. 10 client = 10 workflows phải bảo trì. Tốn thời gian và nguồn lực, scale không nổi.

2.4 Tại Sao Workflow Không Đủ#

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

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 một loạt việc thủ công: xin technical SEO team một 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 một nửa. Nửa còn lại: technical SEO team cần một nơi để thực hiện việc đó -- một 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ả hai 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 một 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à một 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:

Vibe coding giải quyết cùng lúc hai 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).

Ba 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:

Kết quả: zero 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à một 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:

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

Image format và quality:

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 một đ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 hai 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 một 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ả hai 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 một 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.

Từ n8n workflows cứng cho từng client đến một webapp mà technical SEO team tự setup và publish -- hành trình này không bắt đầu bằng việc viết code, mà bắt đầu bằng việc hiểu bài toán đủ sâu qua vận hành thực tế.

Vibe coding chỉ là bước cuối, biến kinh nghiệm đó thành phần mềm.