AI-Driven Technical SEO at Integral Media

From July 2025 to November 2026, I was an SEO Assistant at Integral Media, an Australian digital agency, working remotely from Hanoi. Over those sixteen months I supported technical and content SEO for 30+ clients in home building, healthcare, hospitality, travel, dental, retail and many other areas of expertise.

This is the longest article on this site because it covers the period in which I grew the most. I arrived knowing marketing, content and a lot about games. I left knowing how to choose and validate schema, plan keywords against real search data, audit landing pages, and turn repeated SEO tasks into Claude Code workflows that I, or a teammate, could run again.

The title says “AI-driven”, but the honest word for the work is AI-assisted. AI helped me move faster through research, drafting, extraction and checks. The decisions, and the responsibility for what reached a client, stayed with people.

The skills I built along the way

Working across different clients at Integral Media gave me a broader skill set than any single case study shows. It ranged from finding technical issues to preparing content for publishing, with plenty of practical work in between:

• Technical SEO: Ahrefs site audits, schema generation and validation, image optimisation, and checks for duplicate location-page content.
• Search planning and measurement: keyword research and intent mapping with DataForSEO, finding page opportunities in Search Console, and tracking rankings.
• Content and editorial judgement: blog planning, landing-page optimisation, fact-checking, and keeping copy consistent with a brand’s tone of voice.
• Shopify delivery: product tagging, collection content, and page and location metafields, with review checkpoints before changes went live.
• AI-assisted workflows: turning repeated tasks into reusable instructions, connecting tools through APIs, and documenting checks, reports and publishing handovers.

I collected many of those methods in my public AI-agent skills repository. It shows how I broke the work into repeatable steps, rather than treating each task as a fresh prompt.

Where I started

My first months were about learning the delivery basics: content adjustments, editorial checks, getting comfortable in different CMSs, and following a handover properly. The lesson that stuck from that period is simple and slightly unglamorous: preserve approved content, keep business details accurate, and check that a transfer actually worked instead of assuming copy and paste did its job.

From late 2025, my work moved towards schema optimisation and multi-client delivery. That is where AI tools became central to how I worked, and where I had to learn the difference between an answer that sounds right and a deliverable that is right.

Claude Code, beyond the chat window

The biggest change in how I worked was moving from a chat window to a workflow in the Claude Code CLI in Visual Studio Code, with access through the VPS.

In a chat-only browser workflow, I would paste the brief into a new chat, copy the answer into a document, run checks somewhere else, and carry every lesson into the next conversation by memory. Each task started almost from zero.

With Claude Code, I could work directly with project files and use connected tools such as MCP/API where access was available. Instructions, source material and outputs lived together. When I found a method that worked, I saved it as a skill - a reusable set of instructions with defined inputs, checks and handover steps. When a review exposed a gap, I could improve the process for the next run, not just fix the current spreadsheet.

The efficiency came from connecting the work, not from asking AI to do everything unchecked. I tested a small batch first, checked facts against sources, and kept a clear line between a draft and reviewed or published work. If access or evidence was missing, the workflow flagged it rather than filling the gap with a guess.

A workflow is only useful to a team if other people can understand it. I used Claude Code Workflow Studio to turn a saved workflow into a visual map: each phase, each validation checkpoint and each fallback path laid out as a diagram. A teammate can see what the process does, and where a human needs to look, without reading every line of the instructions behind it.

Case 1: a five-phase schema workflow, and what happened after

Schema work involves more steps than generating JSON-LD. Someone has to pick the pages, extract what is already there, choose the right types for the content, generate the markup, validate it, and hand it over with the task tracked. Doing each of those in a separate chat was slow and easy to get wrong.

So I built a five-phase schema-delivery workflow in Claude Code:

1. Extract the existing schema and the page content, with a browser fallback when a simple fetch failed.
2. Choose schema types from what the page actually contains, not from a template.
3. Generate the JSON-LD.
4. Validate syntax and check the markup against Google’s rich-result expectations.
5. Hand over the output with delivery and task tracking connected.

In March 2026, I reported an end-to-end run on five Travelvax holiday-vaccination pages: Costa Rica, Japan, Nepal, South Africa and Zimbabwe. The pages received WebPage, MedicalWebPage and FAQPage markup.

In the four weeks after the rollout, compared with the four weeks before:

• clicks on the five pages rose from 415 to 683 (+65%), while site-wide clicks moved +1.3%
• click-through rate went from 1.59% to 2.19%, which fits richer search snippets
• over 56 days, the five pages were up 17.7% while the site was down 3.2%
• over 90 days, they were still up 8.6% while the site was down 2.9%; the South Africa page held +36% clicks and its average position moved from 16.3 to 11.7

I am careful with how I describe this. A Google core update overlapped the period, and the deployment date comes from my work log rather than written client confirmation. So this is a result after the change, a strong correlation, not proof that the schema caused it. I would rather show the caveat than a bigger claim I cannot defend.

Case 2: new articles that found an audience quickly

Writing new content was the other half of my role. For Kensington Dental Care, an Adelaide dental practice, I researched, wrote and optimised five local treatment articles: dental treatment options, broken tooth repair, wisdom teeth removal under general anaesthetic, bleeding gums and discoloured teeth.

Within their first month in Google:

• the five articles earned 1,089 impressions
• four of the five averaged positions between 7.9 and 8.9
• the lead article, on dental treatment options, ranked for 51 queries, 21 of them in the top 10

These are new pages, so there is no “before” to compare against, and four weeks is early. I present them as a first month, not a final verdict.

The same pattern showed up for other clients, on a smaller scale. A co-packing article I wrote for an Australian contract packaging provider reached 412 impressions across 38 queries in its first 69 days. Another article for the same client earned 142 impressions, and a finger-food article for a Melbourne caterer earned 174 impressions across 31 queries in its first 49 days.

Case 3: keyword research with a quality gate

Gathering more keywords is not the same as improving a keyword set. Early on, I could produce a long list quickly; the harder part was deciding what belonged on it.

I turned my filtering process into a reusable quality gate. Before any keyword reached a content plan, the workflow checked it for relevance to the client, duplication, search intent and coverage of the page it was mapped to. I applied it across client research such as gas plumbing, travel health and home building, and it helped me remove topics that did not fit a business before anyone spent time writing them.

The same thinking shaped monthly content planning. Checking proposals against existing content and trackers caught topics that would have repeated pages already written, and recorded access gaps and blockers openly instead of hiding them.

Case 4: landing-page audits when the data isn’t there

Not every client gave us Search Console access, and competitor pages don’t always load cleanly. A reusable audit has to cope with both.

I developed a landing-page audit workflow that produced client-facing HTML reports and summary Sheets. When Search Console access was missing, it switched to a manual evidence path instead of inventing numbers to fill the template. The output separated three things: what we knew, what could be supplied another way, and what remained unverified. One example was a completed five-page audit batch for a media-digitisation client.

The lesson I took from it: a robust audit doesn’t fake data to look complete.

Case 5: accuracy over a catchy headline

Two pieces of work taught me that good optimisation sometimes means changing the brief.

Dafra. An air-rivet-gun article had a comparison table with outdated product references. I rebuilt it around four products that were actually in stock, taking capacity, pulling force and weight from their product pages, and flagged questions about discontinued models to the client.

Catalyst Computers. An iPhone article promised eight methods, but some of them were false or obsolete. My fact-check kept the five genuine options, revised the title and H1 to match, and flagged that the changed URL needed a redirect.

The search numbers here are small, and I don’t lean on them. The point is the decision: keeping a catchy “8 methods” headline is not a good reason to keep inaccurate advice.

How I documented the work

Good work is easier to trust when it is easy to follow, so I kept a clear record of it.

At the end of each day, an AI-assisted workflow compiled my daily report from my task tracker and AI usage logs. Each entry grouped the client, the task, my notes, the deliverable link and the AI models used for that task. Anyone reviewing it could see what moved, what was waiting for review, and where AI had been involved.

Two sample daily reports show what that looked like, themed around two characters from the game Honkai: Star Rail:

• Sample Robin daily report: 2 November 2026, a day of landing-page optimisation and publishing across five clients. The report comes with Personalised Robin Cursor, theme template, and integrated music.
• Sample Sparxie daily report: 21 October 2026, a day of content publishing, a rank-tracker update, a site-audit review and landing-page optimisation. The report comes with Personalised Sparxie Cursor, theme template, and integrated music.

My public profile from that time is still on the agency’s site. It describes my work across technical SEO, schema markup, content strategy and keyword research, and a process-driven approach that builds repeatable workflows and validates decisions with Search Console, DataForSEO and SERP analysis.

What changed in how I work

Sixteen months changed how I approach almost every task. Four habits stayed with me:

• Test small before big batches. One page through the workflow before twenty. Problems are cheaper to find early.
• Flag blockers early. Missing access, an unclear brief or an unconfirmed date gets raised on day one, not discovered at the deadline.
• Name the stage. A draft, a reviewed draft and a published page are different things, and I describe them that way.
• Measure after launch. A page going live isn’t the end of the job. I check what happened next, with the time window and the caveats attached.

The common thread is accountability. AI made me faster, and Claude Code made my methods repeatable, but the value came from the checks around the output. I still treat every AI-assisted result as something to verify before it reaches anyone else.

If you want to see where this way of thinking came from, my research work at NEU taught me to separate evidence from hope, and my jobs before SEO taught me to write for a real audience.

Have a technical SEO or AI-assisted content project in mind? Tell me what you’re working on.