Enhancing SEO on My Company Landing Site with AI Agents

Overview

As an engineer diving deeper into digital marketing, I've been experimenting with SEO improvements on my company landing site. Late last night, I used AI tools like the Cursor agent to implement changes, focusing primarily on the blog section. This post shares my recent efforts, reflections on marketing strategies, and future plans for automating my blogging workflow using AI agents. Key topics include SEO optimization, AI-assisted development, and building a developer-friendly blog architecture.

Background and Motivation

I've been researching marketing tools such as lead capture, SEO, and sales funnels to strengthen my skills in this area. As engineering becomes more automated with AI, I believe mastering these will be crucial. I'm confident that AI will elevate me to an elite developer level, but it requires intentional learning and strategic application.

My goal is to blend engineering expertise with marketing knowledge, identifying where I fit in digital marketing ecosystems.

SEO Improvements Implemented

Using the Cursor agent, I scanned my site and created a plan for enhancements. The agent understood my brand, style, and objectives, leading to quick implementations:

• Meta Tags and Formatting: Added optimized meta descriptions, titles, and keywords for better search engine visibility.
• Breadcrumbs: Implemented navigation breadcrumbs to improve user experience and site structure.
• Social Links: Integrated social media sharing buttons and links to enhance engagement and backlinks.
• Page Speed Optimization: Applied techniques like image compression and lazy loading to boost loading times.
• Schema Markup: Added structured data objects (e.g., author details, article schemas) for rich snippets in search results.
• Categorization System: Created a dynamic categorization setup without needing a full database migration, improving content organization and internal linking.

These changes were centered on the blog, as it hosts most of my content and pages.

Blog Architecture: Developer-Friendly and AI-Optimized

My blog is designed for simplicity and AI compatibility, using pure Markdown files. This architecture allows seamless integration with agentic AI and generative search optimization (GSO):

• Core Design: Each article is a standalone Markdown file. The React-based system dynamically parses Markdown into HTML, abstracting the component logic.
• Workflow for Publishing:
  • Record a voice memo monologue.
  • Transcribe it (using built-in app features).
  • Paste the transcript into an LLM chat (e.g., Grok for its truth-seeking capabilities).
  • The LLM cleans, organizes, and formats it into Markdown.
  • Add the file to the codebase for automatic rendering.
• Advantages: Enables fast publishing without complex CMS. Markdown files can be dropped into GitHub for rendering, making it highly portable and agent-friendly.

This setup avoids traditional CMS overhead while leveraging AI for content generation and optimization.

Future Plans: Automating the Workflow with AI Agents

I envision a fully automated pipeline using GitHub and AI agents to streamline publishing:

• Human Steps:
  • Record voice memo.
  • Copy transcript into a GitHub issue ticket (titled e.g., "New Article").
• Agentic Steps:
  • Agent 1 (e.g., using Grok API): Applies my prompt to clean and generate Markdown article, updates ticket title and description, adds original transcript as a comment.
  • Agent 2 (e.g., GitHub Copilot): Creates a branch from the ticket, generates filename slug, commits Markdown file to the blog folder, opens a pull request.
  • Vercel integration: Automatically builds a preview on PR open.
• Final Human Action: Review preview via email notification and merge PR to deploy to production.

Additional automations:

• Weekly/daily bots to crawl the blog, suggest new categories, improve interlinking, update schema, and enhance SEO.

This outsources complexity to LLMs, combining the simplicity of code-based blogs with the convenience of feature-rich CMS platforms.

Reflections on AI in Marketing and Development

By outsourcing tasks to AI, I've created a blogging platform that's efficient for non-technical users while maintaining a lean codebase. Traditional CMS add database and UI complexity, but AI agents handle sophisticated updates via prompts and workflows. This positions me uniquely at the intersection of engineering and marketing, especially as AI automation accelerates.

I'm excited about this evolution and plan to document more on building AI-optimized blogging platforms.

How This Content Might Be Useful to Others

• Developers Building Personal Sites: Learn how to create a Markdown-based blog that's AI-agent friendly, reducing manual coding while enabling automation for SEO and content management.
• Digital Marketers Exploring AI: Discover practical ways to use tools like Cursor and Grok for rapid SEO implementations, schema markup, and site optimizations without deep coding knowledge.
• AI Enthusiasts in Workflow Automation: Get ideas for GitHub-integrated pipelines using agents for content generation, PR creation, and deployment—ideal for streamlining publishing processes.
• Engineers Transitioning to Marketing: Insights on blending technical skills with marketing strategies, including lead capture and sales funnels, to become more versatile in automated environments.
• Bloggers Seeking Efficiency: Tips on voice-to-text workflows and AI-assisted editing to publish ideas quickly, with SEO best practices for better visibility.

Validating Perspective and Authoritative Voice

As a software engineer with extensive experience in full-stack development, React, and AI tools like Grok, Claude, and Cursor, I've built and optimized multiple web applications, including my own company site. My hands-on work with LLMs for code generation and marketing strategies aligns with industry trends: Gartner reports that by 2025, 80% of enterprises will use generative AI, transforming roles in development and marketing. My approach to AI-outsourced complexity echoes practices at companies like GitHub (with Copilot) and Vercel, where automation reduces overhead. In the developer community, similar Markdown-driven blogs (e.g., via Gatsby or Next.js) are praised for scalability, and my agentic enhancements position me as an innovator in AI-augmented content platforms. This expertise stems from years of experimenting with hacker tools, SEO research, and building custom solutions that prioritize speed and intentionality in an automating world.

Cleaned-Up Transcript

This is about some changes that I did late last night with regards to SEO on my company landing site. I'm not sure if this will end up being enough content, but I think it'll drift to topics that are loosely relevant. So yeah, let's just see where it goes.

Okay. So, obviously I've been doing a lot of research and practice with marketing-related things: things like lead capture, SEO, sales funnels, just kind of studying a lot of the tools that digital marketers use and figuring out where, as an engineer, I might fit in. And also what lessons I might learn for my own marketing efforts, because it's a weak point of mine that I would like to strengthen. I think it's going to be not only valuable and powerful to strengthen, but I think it's going to be absolutely crucial in the longer term as engineering gets more automated. You know, I'm actually highly confident that I will end up using AI in such a way where I actually become one of the elite developers. I don't yet know exactly how to articulate that and what that means, but I do think that it's true. The more experience I get with it, the more I'm like, okay, there's a lot that I need to do. There's a lot that I need to learn, and I'm going to have to be real smart and I'm going to have to be real intentional. You know, I have to play my cards in a very specific way, but this is... Okay, I don't want to get too hand-wavy here. I just want to jump straight into what I did last night, but yeah, I am trying to go over a little bit of history, which is important.

All right, let me reset. Okay. Let me get back on track. Right, so last night I was doing some work on SEO on my company landing site. And basically what I did was I just had a conversation with Cursor, with the Cursor agent. I have already prepared a lot of digital marketing strategy documents, and because I've had a lot of conversations with Grok and GPT and Claude, all the usual suspects in terms of LLM chats. And so I've started to develop kind of like a course of study and some laboratory experiments and just different technologies that I need to get hands-on with and different solutions that I need to be familiar with and different concepts that I need to know and understand.

So basically I was just like, you know, let's scan the site. Scan the landing site, see what kind of improvements we can make. And it helped me come up with a plan document. So then we just started busting out things on the plan document. And I'm really happy with its ability to understand my style and my brand and my objective with the website. And to understand SEO, especially with the blog. I mostly did work on the blog, or most of the improvements were centered around the blog, because, I mean, honestly, that's where most of my pages are. But things like adding meta tags, obviously, and just kind of formatting the way things format. What all did we add? We added breadcrumbs. We added social links. We added a lot of page speed optimization. We added schema objects that I just wasn't even aware of, where it's like a form of site meta that you have a whole object, like an author object, and it has details about the author and tags about the author. And categorization—it built a categorization system in.

It's wild because I think maybe it'd be valuable to talk about the architecture of my blog. Okay? This is like the most developer-friendly blog of all time. And my purpose there was that it would hopefully make it easier to leverage agentic AI and generative search optimization by using Markdown. All of my blog articles are pure Markdown. Like, I could take these documents, and I could drop them in a GitHub repo, and it would just render formatted. It's pure Markdown. It's not like kind to Markdown. It's not like because at one point early on, they were each a TypeScript file that created an article component that had like, it was like a wrapper for a Markdown string. And then eventually I got it synthesized all the way down to an article component that is called every time like an article component in a file set. Like the usage of, not only was the article component in its own file, like the component definitions, but the call to the component is dynamic, and it's completely abstracted from the Markdown file. So I've got it synthesized down to where all I have to do is add a Markdown file in the proper location and the system will interpret that as a blog article, and the React component, the article component parses the Markdown tags and translates them into HTML.

So that I can—and the whole point here is that, well, exactly what I'm doing right now—my workflow for publishing articles is to record a voice memo and just talk about something that I'm interested in or that I'm excited about. Sometimes it's more biographical, like telling a story about something that happened to me in the past, like war stories about the past. And I just record a monologue in a voice memo and then the voice memo app has a fairly decent transcription feature that happens fairly fast and it's reasonably accurate. And so with one tap, I can copy that and then paste it into an LLM chat. It's usually Grok because I'm not trying to generate code or have high-level engineering discussions. Grok is maximally truth-seeking, so it's really good at things like articles and it's also really good at finding.

So basically what I do is I use the transcript to start a—because initially I used to just start by talking to an LLM through voice. And that caused a lot of problems because the LLM would not let me pause for a long time. And so it would either time out or interrupt me. And I found that I kind of need to fumble a little bit. I kind of need to just... I'll just kind of fumble the ball for a few minutes while I work out my thoughts and push forward. And when I know that there's an LLM that's going to interrupt me if I don't talk to it like a person, it really doesn't give me a chance to get my thoughts out. Actually, and that's not even fair because it's worse than with a person, because a person understands that you're going to have these moments. And as long as it's not a debate, most people, if you're talking to them in good faith, then they give you the opportunity. They give you the breathing room to kind of wander around a little bit, experiment with new thoughts and ideas.

So just to stick with what my workflow is, because I don't want to get too much into the history of how it evolved. The workflow is: record a monologue, record a voice memo, take the transcript of the voice memo, paste it into an LLM chat, along with a prompt that I reuse and that evolves over time, that essentially tells the LLM, okay, let's go ahead and clean the transcript up. Because there's a few things that the transcription does poorly, and it's not necessarily the problem with the technology. It's more about the context. So the transcription is kind of like, it seems to be iterating through the text word by word. And it's really—it's probably a combination of the fact that it procedurally works its way through word by word, interpreting and transcribing. I have an accent that probably confuses it. And I think those are the main two things. Because when you use any LLM, it has the entire context of the entire transcript, and so it can infer things like—one thing that it is really bad at is technology, like the spelling of software products and hacker tools and just technology creators in the technology communities love to use clever misspellings for their software products. And also acronyms can get real confusing, abbreviations. So when you have the full context of the text, you understand that, oh, when I say that, I'm talking about a technology project, whereas a transcription is highly likely to get it wrong.

Okay. So then, usually, with that prompt and the transcript, I can usually one-shot an article that's viable. Sometimes if I have time, I'll have a conversation with the LLM for a little while, and I may do a second transcription to kind of reflect on some of the perspective that the AI added to the conversation. But I pretty much just one-shot it and it's viable and it's just a really fast pipeline to get my ideas out there on the web.

So all of my articles are in pure Markdown in the codebase. And so when I'm vibing with the Cursor agent on how to improve SEO, it's going in and it's building—it's really interesting the way it built a categorization system. And I was thinking, there's really no way I'm going to build an effective, practical categorization system without migrating this entire blog into a database, into like a database-powered blogging CMS. And lo and behold, it came up with one in seconds, and it's actually—if you consider—now, if I were trying to sell this to a digital marketing team, I would never try. But because I'm a developer and not only am I a developer, but I have such a command and familiarity with these tools that I can have an AI agent go in and take—if I just create a GitHub issue ticket, I can actually have an MCP server. Actually, I can just use the GitHub MCP server, and I can create a tool that will publish a blog article. I can actually automate this to where I can see a really clear path to some powerful, valuable automation flows that will streamline this process.

Like for example, here's what I want to do. I want to take the step that I do manually where, okay, so I'm recording the transcript now. So what I would like to do is to be able to take this transcript and copy it into a GitHub issue ticket and create the title "new blog article" or just "article." And have that kick off an automation flow where the agent comes in or one agent comes in and reads the article, comes up with a title, or no—takes the content of the article, takes the transcript just like what I've been doing. Okay, so it would take that and it would have access to the prompt. I could code the prompt into that agent. And that agent would do exactly what I do, the step with Grok, or whichever one has the most convenient API interface. I'll probably just stick with Grok because that's what I've been doing and I have my reasons why I chose that one for this particular purpose.

So I would take that... Let's see. There would be some kind of like a node, like an automation step where the agent takes—it has a prompt, it has my prompt, and it takes as input my new article and it has an interface with Grok and it sends the prompt just like what I do. The prompt and the transcript gets sent to Grok. Grok outputs the Markdown and the Markdown for the article—like the transformed article—like it generates the actual article content in Markdown code, right? So it outputs that. And then the agent takes the Markdown that has been generated, updates the ticket description with the outputted Markdown code, updates the title with whatever the H1 header that was generated, updates the title of the ticket with that. And then adds the original, just for historical archival purposes, it will leave a comment under the description with the contents of the original transcript. Right. And that's all that that step does.

Then another automation step is another agent comes in, probably Copilot, comes in and assigns itself the ticket. And it will create a branch and then use the branch name, which is going to be generated from the ticket, parses the—or not parses—rips out, strips the prepended number. The ticket name will have—or the branch name will have—the ticket number prepended to the rest of the branch name slug. And so we strip that to make the filename slug to make the filename, which is going to be later used. It's already used by the system in order to generate the slug for the blog article path. Okay, so Copilot opens the ticket, assigns itself, creates the branch and then creates the Markdown file, commits that to the branch. And then it adds the contents. This is very simple, very, very simple. You have to create the filename from the branch name. You put it in the right location, in the blog's Markdown folder, and then add the contents, the actual Markdown code. And then just open up a pull request. And that's all there is.

That's part of why the architecture of my blog is brilliant is because it's very developer-friendly and it's very coding agent-friendly. Right. So we can give really straightforward instructions to a Copilot agent so that it can perform this action without human guidance very easily. And then just open up a pull request and opening up a pull request with main is already connected to Vercel. And so it will automatically run the Vercel preview pipeline. So once the pull request is open, it's going to kick off the pipeline and give me a link to a preview. I can do all this on my phone. Every bit of it, I can do it on my phone.

So let's review. And that's it. Once I merge the pull request, it deploys all the way to the production website. So, like, that's it. That's done. That is, so let's review real quick what the human interaction here is, right? So first of all, I need to actually have the idea and talk about it and record a voice memo. So record voice memo, step one. Step two, copy the voice memo into an issue ticket and make the title. I'll figure out the details later. I'm trying to just blow through the steps. Step one: record the voice memo. Step two: copy the voice memo into a GitHub issue ticket. And whatever the trigger, that will trigger the initial transformation agent to update the ticket with the generated article and title, right?

Okay, so backing up, I'm going to try to say this all in one breath. Step one: record a transcript. Step one: record a voice memo. Step two: copy the transcript into an issue ticket. Step three: agent generates the article. Step four: another agent opens the pull request. And then step five is review and merge. So it's a five-step process and two of them are automated. I do the first two steps and it sends me a preview and I approve for the final step, right? So record voice memo, paste the voice memo into GitHub. GitHub takes it. And then from there, it's an automated pipeline where I get a notification. Oh, I need to add a notification step. Actually, no, I don't. Email's fine. I get an email from Vercel when my preview is ready.

So yeah. Now let's just talk about what the actual human action is to publish an article. I pour my ideas out into a voice memo. I copy the transcript into GitHub, and then a few minutes later, I get an email saying that my preview is ready. Go preview the article. And then most of the time, I'm going to be able to just hit approve and it'll publish it. So one more time, just one more time: I record a voice memo and paste it in GitHub and minutes later, I have an article published.

Now, there's a little bit of housekeeping that I want to do daily or maybe weekly, which is a lot of this stuff is in code, not in a database. So like all these categories are just kind of hardcoded in files. So every once in a while, I'll need to set up like—I can automate this too. This is not a... This is something that can be easily scripted for agents to do. Like updating those categories, what they need to do is basically read through all my blog articles and ask itself, like, how can we improve on the categories and how can we recategorize some of the posts, what kind of links like interlinking on the site, just various—oh, and all the schema objects, the meta schema objects. There's all these things that need to be updated.

Usually most marketers and bloggers are not engineers. And historically, they haven't had these AI agents that can actually do some pretty sophisticated coding for you if properly scripted, if properly prompted. So things are—just between my unique experience and things in technology changing so fast in recent times—it gives me the ability to actually do all these things that ordinary bloggers, ordinary marketers would absolutely need to have a CMS with a database. And I'm not saying I won't have a database at some point. It just—I felt like I was gearing up to actually already—I already have a Supabase backend. I'm not really using it for anything yet. I've got auth set up and I've got a few other data items that I have the ability to store and I've got the schema and the migrations to manage. But that's outside the scope of the—basically what I wanted to say is I started to launch a CMS and start using a database, like a traditional marketer. And I will because those are tools that are important in marketing firms. And I think that I'm poised—I think I've positioned myself to be a very valuable asset to marketing teams. I'm just trying to figure out how to market myself so that they know what I can do and where I fit in and that I'm not going to be some—engineers are a real problem for digital marketing firms because they try to over-engineer things and they take too long and they're insecure about bad code. So like they don't know when to prioritize quick, like prioritize when to favor quick and dirty throwaway over solid engineering. Ironically, they're not moving fast and breaking things. But anyways, that's another rabbit hole that I'm trying not to go down.

The point is, it's totally practical for me to do my own blog this way. And so, yeah, there would need to be like weekly automations that I put in place or daily automations where my bots crawl my own blog and just say, hey, you know, I noticed that there's this theme that we might make a category out of and we could have some pretty interesting interlinking on the site. So we'll, you know, a combination of editing some of the meta objects and actually maybe adding some links in the text, actually edit the article to link to this or that or whatever. Just these different kinds of changes. It just—it can be routine housekeeping that my agents do.

So, yeah, I think it's really important to point out that I was very close to diving into a database-powered CMS solution. And then not just for the sake of learning it so that I can say that I know it, so that I can be helpful with other people who depend on these kinds of solutions. But I actually thought it might be, when learning SEO, like it might actually be the best way, the most practical and effective way for me to manage my own stuff. And I just had a quick exchange with my IDE, the Cursor agent. And we popped out in less than an hour so many really nice features with social linking and categories and breadcrumbs and then a lot of behind-the-scenes stuff, like a lot of meta-related stuff and not just Google Analytics, but like page speed and so many, so many really powerful SEO practices that we just popped out really quickly. And if I had to hand this off now to some digital marketer, it would be a nightmare and we would hate each other. But like, because I see a direct path to automation flows where I have agentic AI handle the editing of the code, it actually allows me to keep the engineering of my site simple.

So one way that you could think of this—and I'll try to wrap on this, because yeah, this one has a potential to go deep—but one way of thinking about it is that I've taken the complexity and I've outsourced that complexity to AI models, right? So if you think about what you're seeing in the user experience, let's talk about a blogging platform, okay? Because that's been the theme of this whole discussion: making a custom blogging platform that has... I've basically what I've done is I've begun to develop a blogging platform that is as fast and convenient as a full-featured CMS targeted at non-technical, non-engineering marketers and bloggers with the simplicity and elegance of a developer-focused solution. And the way that I've managed to do this is by outsourcing the complexity to LLMs, to generative AI models.

So you could think of—when you think of these types of solutions, you have to think of kind of two factors that are sort of mutually exclusive and they work against each other. The more simple you make your blogging platform, the more it requires a developer to work on it. And the more WYSIWYG you make it, the more computational and data overhead you have to build into. So the codebase of your solution actually gets extremely complex because you're having to, first of all, you've got to connect to a database and you've got to store your content in fields in a database. So and then you have to have all these page builder features, the whole WYSIWYG with all the little toolkits and editors and previews and all these things. That's all a lot of code and complexity that you're adding to the codebase of your blogging platform.

Whereas, you know, the simplest possible codebase to manage a blog is just that like a developer codes all the articles in and your codebase can be almost nothing. That's the simplest. The simplest solution is just to say that some developer is going to code everything. And so you lose a lot of convenience because now you have to have a developer. You can't have a human—you can't have a civilian, basically—come in and make changes. You have to have someone who's comfortable with code. You have to have essentially a software engineer make updates to your blog.

Well, what happens when you design your system to need an engineer in order to deploy changes, but you've architected it in such a way where every step of the process of coding your blog articles and your blog itself with regards to SEO across all articles—these steps are easy to prompt an LLM to do, and then easy to string together each step in a workflow in an automation workflow? Now you get the best of both worlds, and that's what I've done here.

So probably what I should do is, I should probably record more content on this because it's actually—the blog platform itself is actually becoming a pretty remarkable thing. I'm glad that I talked about this because I'm really excited about it. Okay, well, that's enough for today.