Nick Swan breaks down the future of SEO experimentation, MCP servers, and automated search optimization workflows. If you want to understand where technical SEO, AI agents, and search analytics are heading next, this episode is packed with insights youβll want to hear all the way through.
https://page2pod.com - In this season finale of the Page 2 Podcast, Jon Clark and Joe DeVita sit down with Nick Swan, founder of SEOTesting, to explore the future of SEO experimentation, AI-powered workflows, and the rise of MCP servers.
Nick shares how he accidentally built SEOTesting from a side project tracking coupon code SEO changes in Excel into a leading SEO experimentation platform used by agencies, consultants, and enterprise teams. The conversation dives deep into statistical significance in SEO testing, content refresh strategies, AI-assisted development with Claude Code and Codex, and how modern SEO teams are adapting to Googleβs evolving search landscape.
βοΈ In This Episode
β’ π Nick Swan explains how SEOTesting evolved from a side project into a full SaaS business
β’ π A practical explanation of statistical significance for SEO experiments
β’ π€ How Claude Code and Codex are accelerating software development
β’ π Why content refreshes consistently outperform many SEO tactics
β’ π§ Using Google patents and AI to generate better SEO personas
β’ π How MCP servers connect SEO tools, AI workflows, and automation
β’ π Lessons from analyzing over 140,000 SEO tests
β’ β‘ Why AI agents may soon be making SEO changes autonomously
β’ π οΈ Insights into building scalable SEO workflows for agencies and in-house teams
β’ π Nickβs favorite startup and productivity resources for founders
The episode also explores:
β’ How SEO split testing actually works
β’ Why content refreshes remain one of the highest-performing SEO tactics
β’ How AI workflows and MCP servers are reshaping SEO tooling
β’ The role of personas and query fan-out in AI-driven content optimization
β’ Why agencies and enterprise teams still need reliable SEO infrastructure
β’ The future of automated SEO monitoring and agentic workflows
β’ Startup lessons from bootstrapping a SaaS company for nearly a decade
This episode is packed with actionable SEO insights, AI workflow ideas, and startup lessons for marketers, founders, and technical SEOs alike.
π οΈ Tools & Resources Mentioned
β’ SEOTesting.com β https://seotesting.com/
β’ Nick Swan on LinkedIn β https://www.linkedin.com/in/nickswan/
β’ Nick Swan on Twitter β https://x.com/nickswan
β’ SEOTesting MCP Server β https://www.loom.com/share/07db5eddb12b44b1abca348895d567df
β’ SEOTesting.com 45 Day Extended Free Trial Offer β https://seotesting.com/partner/page2pod/
π£ Subscribe to the Page 2 Podcast for more interviews with leading SEO founders, growth marketers, and AI innovators shaping the future of search.
π¬ Comment below: What SEO workflow or AI automation are you most excited to test in 2026?
Jon Clark: Welcome to the Page 2 Podcast where we uncover the strategies, systems, and tactical decisions that move brands beyond Page 2 and into real visibility across search and answer engines. SEO has always had a measurement problem. You make a change, traffic moves, and then everyone argues about whether that change actually caused it. AI is making that question harder and a lot more important. Today we're joined by Nick Swan, solo founder of SEOTesting.com, a SaaS product used by agencies, in-house teams, freelancers, and publishers to track whether SEO work is actually moving the needle. We get into statistical significance, why small sites need different testing frameworks, why content refreshes keep showing up as one of the most reliable SEO experiments, and why teams rarely revert failed tests-they just keep iterating. We also dig into the next layer of SEO tooling, MCP servers, Claude Code, AI-generated summaries, log file analysis for LLM crawlers, and whether agencies should build their own tools or rely on products that become the system of record. Nick also left Page 2 listeners an extended 45-day free trial of SEOTesting at seotesting.com/partner/page2pod. You can also find that link in the show notes. One last quick programming note: this is the final episode of season five. We'll be republishing a few previous conversations over the next few weeks before coming back with new episodes. If you learned something new today, subscribe, leave a rating, and let us know what resonated. We'd love to hear your thoughts. Okay, let's get into it.
Jon Clark: I'm Jon Clark and I'm joined as always by my partner at Moving Traffic Media, Joe DeVita.
Joe DeVita: If you've ever made an SEO change and then spent the next six weeks staring at Google Search Console wondering if it actually did anything, today's guest has built the tool that answers that question. He's the solo founder of SEOTesting. Nick Swan builds the features, supports the customers, writes the docs, and still finds time to manage a U14 girls football team in Bude, Cornwall. Nick, welcome to the show.
Nick Swan: Thanks for having me. Thanks for asking me on, guys. It's a pleasure to be here.
Joe DeVita: This is the season finale episode, so we've got to make it great. I've been trying to keep up with all the things that you're doing, and it blew us away how busy you are. You're married, you've got three kids under 12, and you're leading this software company while playing a lot of roles within the company. You're competing in cycling, I can see you're swimming all the time. So you're managing work and life really well, it seems from social media. Can you just talk us through how you organize a typical week to fit everything in?
Nick Swan: Yeah, so I can be honest now and say the cycling has dropped off. There's no more cycling going on at the moment; that was a particular period of my life. Coaching the under 14 girls football team has taken over that free time I had for that. It is interesting with kids; we are super busy with kids. I always said I was never going to be one of these parents whose kids go to lots of sports clubs and we're forever driving them around, but we've accidentally fallen into that trap. Even worse, I manage one football team, or soccer team, and my wife manages another soccer team that another child is involved with. Perhaps you've been in there as well when they say, "We need some people to step forward to manage these teams," and no one puts their hand up and you're kind of like, awkwardly, "Yeah okay, I know a bit about football, I'll have a go." Swimming is good because that gets me out of the office with some friends. It is cold water swimming at Bude-we have a sea pool here so it's kind of cold water immersion therapy. We go for a nice lunch afterwards and a coffee as well. I just enjoy what I do as well, so it doesn't feel like work. But the football is definitely-and this is a warning for anyone getting involved in youth coaching-it is definitely a part-time slash full-time job on top of what else you do.
Jon Clark: Yeah, for sure. I was curious, when you started building this tool or this company, is there anything that you thought you knew about SaaS that has changed since you're now building it and a number of years into the process? Anything that is just very different than what you expected?
Nick Swan: Yeah, I think when we're looking at different business models, the grass is always greener on the other side. This is perhaps the same for an agency as well. From a software provider point of view, I look at agencies and go, "That looks like a good business model." And I know agencies look at tools and go, "That looks like a good business model." The grass definitely isn't greener on the other side; there are always problems. Support and dealing with customers-not just dealing with them, but supporting them-is a time sink and you have to find ways of dealing with that. It's often improving the product and making the product easier to use, but it's also documentation and keeping it up to date. I will say that I got into this by accident. Back in 2016, I was running a voucher codes website, or coupon codes website as you're perhaps more familiar with in the US, with a friend as a side project. We were doing the processes that I built the tool for manually. We were changing page titles and meta descriptions, trying to increase the click-through rate. If we got a two or three percent increase, we could see an extra few hundred dollars a day on coupon codes, and I was tracking that in Excel. I was that person who was looking at these numbers every day in Google Webmaster Tools, as it was at the time. It was really from scratching my own itch that Sanity Check, as it was called initially, came around. I shared it with some friends, as you do. One of those friends actually is still a customer now, which is testament to his use of the tool. He and some other people gave feedback that this was really interesting and I should look into building it out. It accidentally took on its own life and became its own product from there.
Jon Clark: I love that. Total side tangent, but are you still doing any affiliate websites or is SEOTesting your primary focus where you put all your efforts?
Nick Swan: SEOTesting is the main focus now. The coupon code site is still around and I keep thinking about revisiting it with AI being able to do a lot of the human-in-the-loop processing stuff that we were doing previously, but SEOTesting is full-time now. With all the different things going on, I don't really have time for another project right now.
Jon Clark: Right, exactly. I wanted to get right into the testing side of things. Maybe to start, talk a little bit about statistical significance. Whenever you're running any sort of test, you need to figure out what that significance is to say it was successful or not. That is not all SEOs' forte-modeling those things out or using tools to figure that out. In your experience working with a lot of different customers and being a self-service model, how important is that side of analysis and analytics when someone is starting to roll out tests?
Nick Swan: Well, quite a few thoughts. I'm not a mathematician; my background is in software engineering and SEO. I had to learn the statistical significance side of things as I was building the tool out and customers started coming to us and asking, "Has this test hit statistical significance?" I was like, "What's this statistical significance thing?" Like a lot of other people, I thought the significance part meant whether the test showed enough of a significant uplift to be significant to the business. But when looking into it, I've got a way of explaining it that if you are educated in maths and statistics, you may hate, but this is my explanation: it's about the reliability of the data and whether something has happened by chance. If you get a graph and you average out the points and you get a nice line, there are two ways of getting that line of average. You can have dots that trend nicely around the line, or you can have random data that zigzags up and down. They average out the same way, but the one where the dots are closest to the line is statistically significant-the data is reliable. The one that's random and up and down is not statistically significant; that data is happening by chance.
Joe DeVita: It's still hard when you don't have a lot of data. There are a lot of small sites with 10,000 or less visitors every month. It seems like you have to test forever. Do you work with a lot of small sites like that? If so, have you seen any incredible lessons from a small site that would be a good lesson for a bigger site?
Nick Swan: That was the other bit about statistical significance I was going to mention. A site that's getting 10,000 visits a month sounds like quite a lot, but that only breaks down to about 300 or so clicks a day, which isn't a huge amount. With our tool, we have two main types of testing: time-based testing, where you look at a page or a group of pages before and after, and SEO split testing, where you bucket the same type of page into a test group and a control group, and you only make the change to the test group. With smaller sites getting less traffic, time-based testing can sometimes be the only option. It's still valid, even though you're only looking at one page. If you see an increase in clicks, you can look at the overall site trend to see whether it has gone up or down at the same rate to have something to compare it against. If you're looking at a page that's only getting a few clicks a day, you may not be able to reach statistical significance, but you can still look at other data points. You can test on a page and a target keyword as well. If you've got a high-value keyword and you're able to take it from position 22 up to position five or six, that's going to be more important than the traffic from a low-volume keyword that can't reach significance.
Jon Clark: Yeah, so in a sense, measuring the visibility gain, which over time-even if that keyword has low search volume-will translate into meaningful clicks.
Nick Swan: Definitely, especially if it's a high-value keyword depending on the industry. That's why it's also important that we connect to Search Console and Google Analytics so we can bring through key event data. We can track through to conversion. Even if it is a low-traffic keyword, you can see the vanity metrics like clicks, impressions, and average position going up, but you can also track it through to the sanity metrics the business ultimately cares about, which is the return on investment of form submissions, purchases, or signups.
Joe DeVita: How do you get to see what is succeeding and not succeeding? With all the clients using your software, do you have a way of understanding high-level the tests that are being run and what's winning and losing? Or do you have to have conversations with customers?
Nick Swan: Both. We can see some visibility; I get an admin backend email every day saying these are all the tests that have finished. I can see the tests customers have been running and how they've been doing from a clicks, impressions, and average position point of view. We keep an eye on that to see if there are any trends. That's a lot easier now with AI in terms of summarizing data. But then we also talk to a lot of customers to keep the conversations going in terms of what they're working on and what they're testing.
Joe DeVita: I'm curious, there's got to be a really boring test. Is there a boring test you see over and over? Like, "Oh my gosh, another person is testing this, it's clearly going to win." Is there something boring that everyone should try to do?
Nick Swan: We've checked out the data for this. Interestingly, for our business-we've been around just about coming up to 10 years now-I wanted to put some stats on our About Us page for AI to use to see how viable we were. I looked up the number of tests run on our platform recently, and our customers in total have run about 140,000 tests. That's quite a big sample size. The majority of those are single SEO tests on one individual page. It's not particularly exciting, but the one test that's run the most where you always see a change, whether it's up or down, is content refreshes and content rewrites. Keeping content up to date and fresh-we know Google likes that. Now we're learning LLMs like that as well in terms of freshness. One thing I found really interesting from speaking to our customers is that when I was pitching the product, I was doing it as, "Make the change, track the results, and if it's not good, you can reverse it." But speaking to customers, we found that people don't reverse those changes; they just iterate onwards from there. They'll take a page, make the refresh, and track it. If it's not a good result, they won't revert back. They'll go again and again until they get the result they are interested in seeing.
Jon Clark: Super interesting. Maybe where we should have started: you mentioned your ideal customer. Who is that?
Nick Swan: Well, it's changed recently. We know good guidance is to only have one ideal customer profile, but we've ended up with four. Agencies-people looking after lots of clients who need to keep track of lots of data. In-house SEOs-one of the ways people use our tools is for experiments and running tests, but we also found that people were just using the time-based testing framework as a reporting mechanism. They're given a job of making changes to a page and they just want to be able to show, "This is how it was doing six weeks before compared to six weeks after." Rather than having to go to Search Console and set up filters every time, they can just set up the test in our tool. It tracks the data and lets them know when it's finished so they can present it to stakeholders. Freelance consultants use it for a similar reason. The fourth one that has reduced is content publishers. Mommy bloggers isn't the right word, but people publishing recipes and that kind of thing used to be a big sector. But with Google reducing informational content and having AI overviews at the top now, those sites aren't generating as much traffic, and for some, the traffic has gone completely. They are a much smaller part of our customer profile.
Jon Clark: We've been working with Claude to tap into monday.com, which is what we use for our project management, and try to pull down tasks that were completed for the month and connect that with Google Analytics and Search Console for reporting. ΠΠΎ the connections are clunky. Your approach to just highlight changes being made and the impact sounds a lot cleaner. We've got to give that a spin.
Nick Swan: You could try the MCP server for that now as well. That's something we've just released recently and people have been loving it.
Jon Clark: Yeah, let's dive right in there. You originally launched a Google Search Console MCP as a test case to learn how that framework worked. What did you learn from that release that you were then able to apply to the SEOTesting MCP?
Nick Swan: Free tools are one of our marketing efforts-putting things out there that people can use for free, which helps build links and get your name out there. When the MCP framework came around, it was a bit of a race because we knew someone else was going to do it. I think on exactly the same day, two of us published our MCP servers. It was as much a learning exercise as a marketing thing. Off the back of that, we published our MCP server. It did reasonably well, but we haven't developed it any further because the Search Console API hasn't really changed since then. But then we built our own MCP server for SEOTesting itself, which pulls through Search Console data from the reports we have built and configured. You can also use the SEOTesting functionality for creating tests and annotations. It's one of those things that people didn't actually ask for, but with Claude Code and Codex, it was a weekend project for me. I didn't have any football that weekend. We already had an API, so the MCP server just sits in front of it and describes the API so the LLM knows how to interact with it. With Claude Code, I was able to say, "These are our API endpoints. I'd like to write an MCP server." It did it and got it working locally. I was like, "This is magic." This is one of the benefits of Claude Code and Codex-being able to build proof of concepts quickly. We always have ideas we think are great, but when you build them, they don't always work out as you hope. Customers don't always use them the way you think they will. This is one of the things that people have really started to use. We can see which customers have been using it, and that helps start conversations. We have customers who use Claude but haven't perhaps figured out how to bake the SEOTesting MCP server into their workflows yet. I need to speak to the people who are using it, help build out workflows or documentation, and then share it so other people can learn too.
Joe DeVita: The server you released maybe six or seven weeks ago, I think.
Nick Swan: Yeah, it was relatively recent.
Joe DeVita: I watched a Loom that you published on a how-to. You mentioned the endpoints that you chose initially-there were 27 endpoints users could interact with. You get to see exactly what people are doing with it. Of the 27 endpoints, what's bubbling to the top?
Nick Swan: Some of the reports we have. One issue you might find if you're building your own MCP server is that if you make lots of requests to Search Console, it can time out because it's passing a lot of raw data back to Claude to deal with. With our API, it sits in the middle, requests all the Search Console data, and aggregates it-such as the content decay report-and then passes that aggregated data to Claude. It passes a lot less data. It's about building workflows and chaining different things together. In the video, you saw that you can ask for the content decay report. What's really interesting is that Claude did a great job of building it another way where it filtered by sections of the site-blog section versus documentation. You can take our data and visualize it in a completely separate way that makes sense to you. We also have our lab section tools, which help you come up with suggestions for improving pages. I haven't set this up yet, but you could in theory set up a WordPress MCP server to actually publish those updates for you. Within the MCP server, you can just say, "Made a change to this URL, create the test for me," and it will go and create the test with sensible defaults. We've seen some customers twin the MCP servers together-if you are using Ahrefs, you can use their MCP server to bring through link information. You can bring multiple MCP servers together effectively.
Jon Clark: It's amazing. You mentioned the content evaluator. There was a great case study shared on LinkedIn by Alex Galinos where he was using the persona generator in your lab section to build out personas based on keywords for individual pages. Then he would run that content through the content evaluator and identify the gaps. He was using the MCP to facilitate a lot of those tests once that data came back. Talk to us a little bit about those two tools: the persona generator and the content evaluator. How does that persona generator work based on keywords? Are those being pulled from Google Search Console?
Nick Swan: I'll give you the source of how you can build this type of tool yourself. Mike King wrote a big long article on Search Engine Land about preparing for LLMs and GEO. He referenced 10 or 15 Google patents within the article. I thought these Google patents had great information for reverse engineering stuff. Historically, you'd have to read those patents and fully understand them, but now with LLMs, you can give it to ChatGPT and ask for a summary of how it can help you with your work. Within our lab section-this is our experimental area where we encourage people to create tests-our tool makes suggestions about improvements people can make. I built out this lab section as a set of skills that you build for Claude Code. Me as a developer, I'm comfortable working in the terminal and with Claude Code, but not everybody is. So that lab section ended up being a bunch of skills with a UI that looks familiar to people who use SEO tools. One of the first skills we built was a query fan out generator. I took those Google patents, put them into ChatGPT, and asked it to generate a prompt that would effectively take the information within those patents and build out the functionality. It generated the whole prompt for me. There is more to it in terms of the amount of data you pass back and forth, and you need some developer skills to know what's going on in the backend, but what I was trying to do was take an initial query and fan it out so we could do some cosine similarity to see if we were answering that query on the page. Because I asked ChatGPT to help me build the tool out, it built the whole section about user personas for me. It says, "You need to start thinking about who the users are that are actually typing in these queries." I've been blown away by that. We always say to put yourself in the shoes of your customers, but the LLM actually does this for you. It says who those personas are, what they think about, their concerns, and their questions. Just having those user personas is really interesting. As Alex mentioned in his post, it helped them build a tool that their user personas specifically would be interested in using, and that tool is what's done well and driven traffic. Take these patents, put them into LLMs, and ask how they can help you with your work because that's what we've effectively done.
Jon Clark: It's really smart. You've definitely evolved the tool a ton, especially with AI and figuring out ways to identify queries and update content. How do you see the future of SEO tools evolving? Testing tools or even rank tracking tools are struggling as well with the removal of the number equals 100 parameter; they're sort of hamstrung beyond Page 2 and 3.
Nick Swan: Totally. It goes back to how we can be a good tool for people. Ultimately, if people set up tests within our tool to track the results of changes, that's where we deliver value. Some customers slot nicely into that and make it part of their SOPs-whenever they make a change, they create a test. Some customers sign up but it doesn't make it into their workflows, and within three or four months, they churn. I've tried two or three times to build a page monitoring system. In my brain, what we want is to monitor your site or the client site-kind of like ContentKing that was bought by Conductor-and let you know when pages are changed. Not all clients are great at letting you know when they're making changes. If we notice changes, we can alert you and say, "We think you should set up a test for this content group because we noticed these pages have all changed at the same time." I built a couple of proof of concepts and it was on the back burner, but I had a thought as to why this could be important: people are building more agentic workflows. It's not necessarily going to be humans making changes anymore; it could be LLMs and agentic workflows making changes that we don't even know about unless we have a tool monitoring those pages. This is another use case for this page monitoring tool-keeping an eye on the website, the agents, and the changes behind the scenes. Then we would suggest, "We've noticed that these 10 pages have changed within this cluster; why don't you set up a test for it?"
Joe DeVita: I've heard you say 99 percent of your code is developed by Claude Code recently. I assume you're also using GitHub. How many things have you started on GitHub that nobody can see because they just aren't ready? How many ideas do you have in the chamber ready to go?
Nick Swan: We built a prompt watcher a year and a half ago and I was never happy with it because of the data being synthetic, but then everybody else seems to have built that and be selling it anyway. So we've got two or three prompt watchers within GitHub that we never released. To be honest, most of the other stuff we have built proof-of-concept wise is in that lab section. We're quite clear that it is a beta section and stuff in here is proof-of-concept, user-beware type stuff. People like trying new stuff, so it has worked both ways of helping us get stuff out and keeping customers excited. The log file analyzer is a good example of stuff that should work that hasn't. As a product person, we try to do customer interviews and talk to our customers as much as we can, but until something's in front of them and they can push a button, you don't necessarily know what is going to be useful or what's going to fit into people's workflows. It's trial and error, but that's become a lot easier now in terms of being able to build these proof of concepts and get them out quicker.
Jon Clark: I was going to ask: do you prefer Claude, Claude Code, or Codex?
Nick Swan: That has changed just within the last day or so. I have been Claude Code all the way, but within SEOTesting, we did a big release and a big rewrite of our main web app that we went live with back in January. But we've got a lot of legacy code running in the background, and I expected Claude Code to be able to migrate this legacy code over really easily-it's a perfect use case. It just kept messing it up all the time. Some of this code was written back in 2016 or 2017; that's how legacy it is. I'd ask, "Have you covered this bit or this edge case?" and it goes, "Oh no, thanks for pointing this out to me." I shouldn't have to point this out. So I said, "Right, now's the time, let's try Codex." Literally just yesterday. Codex seems to be doing it really nicely, so we shall see. It's like, what a time to be alive, right? We can get these things built so quickly.
Joe DeVita: If there was another SaaS product you could bring to market-maybe in marketing, maybe not, but definitely not SEO-what do you think you'd enjoy building?
Nick Swan: It'd be something like an amateur football club management software. I go to these committee meetings and people say they're going to do stuff and they never get done. The committee meeting minutes, the marketing website, the writing of match reports-I've been this close to starting that out. I probably will. I've had a couple of businesses before SEOTesting and tried others that failed. The ones that have done well have always been ones where I solved my own problem initially. You try and build for someone else and you lose interest, whereas I'm always solving my own problem. There's always one customer, and it's always me at least. I've been lucky in terms of finding other people who found those tools useful too.
Joe DeVita: So maybe a tougher follow-up question. It is a little bit easier to build tools, especially point solutions, if you're only trying to do one thing. Your product solves a lot of problems, but if somebody only really needs to solve one problem, they might have the initiative to build it themselves. How are you thinking about holding on to that customer who's savvy enough to build their own point solution but can still benefit from subscribing to a tool like yours?
Nick Swan: We've lost customers who have done that exact thing. All power to them; to be honest, it's what I would be doing, so I can't really begrudge people going off and doing it. They're more freelancers or consultants who have that hacker mindset and want to improve their own processes. This goes back to our ideal customer being more of an in-house team or an agency. My working thesis is that an in-house team of a multi-million dollar e-commerce business doesn't want to rely on Bob, who's vibe-coded an application. They might do this once, but then when Bob leaves in three months' time and this was a critical piece of their workflow, there's no one to support it. I think there is still a place for tools like SEOTesting that are business-critical.
Joe DeVita: I just have a suggestion. You have a big community of customers. Getting them together, not in a conference but in a way for them to learn from each other, would be unique to you.
Nick Swan: We've got a Slack channel and we've actually tried to build a little bit of community into the tool itself-a little discussion forum. I think that's a positive thing for us. As you say, if you vibe-code a tool, it's just you using it. Whereas if you've got a community aspect, people are sharing ideas, tips, and industry news, and that builds the community within the tool itself.
Jon Clark: That's great. Let's transition to a couple of rapid-fire questions. Is there a book or a podcast that you'd recommend that has helped shape how you built SEOTesting?
Nick Swan: From a SaaS startup point of view, I'd recommend Startups for the Rest of Us, which is Rob Walling's podcast. It has got hundreds of episodes. If you're interested in bootstrapping your own software business, that's a great one to check out. In terms of AI, Cal Newport has got a great podcast. He wrote Slow Productivity, Deep Work, and Be So Good They Can't Ignore You. It's good to listen to his ideas about slowing down, being an expert, and not rushing. While it is very exciting, still focusing on being an expert within your field is important.
Joe DeVita: Is there a piece of advice or message you remember from Rob Walling you could share with our listeners?
Nick Swan: There are quite a few. He's got a good book actually, The SaaS Playbook, which I'd recommend. You'd think it would be about sales and marketing, but the best bit of advice I've taken from his podcast is about taking a founder's retreat. We're so far into the work, deep in the ditches, digging holes, and writing code that it is good and important to take a step back every now and again. I try and do it once a year at the beginning of the year. Annoyingly, we get through Christmas and then we've got two kids' birthdays within the first couple of weeks of January. I can never start the new year until those are out of the way. But then into the third week of January, I'll always try and take a founder's retreat where I'll just disappear by myself for two or three days and think about things. I write in a journal every day or two, so I'll review that journal and think about what I want to achieve in the next 12 months. Taking that time away from the computer is important.
Joe DeVita: Incredible. I find cycling is great for that too. I don't cycle in a group; I cycle by myself. When I go out for a couple of hours on a bike, I fill myself with ideas. One more rapid fire: is the cycling better where you are now in Bude, or was it better when you moved from Reading?
Nick Swan: I didn't cycle in Reading, funnily enough. Peak cycling was during COVID lockdowns because there were no cars on the road. It was just different being out on the road and not having to worry about what's coming behind you to overtake. Just after COVID, I did Land's End to John o' Groats-one end of the country all the way up to the top.
Jon Clark: Is there a feature or a component of the tool that you'll ship in 2026 that you can pre-announce?
Nick Swan: I probably mentioned them both already: the page monitor and the webhook side of things. We already have a sitemap monitor where we use the lastmod date to tell you which URLs have been added or changed, but we can't tell you what's changed on the page yet. We're going to get to being able to tell you what's changed. And also the webhook side-being able to push events and data to you instead of you having to pull it yourself.
Jon Clark: I had a question about that. Are you thinking about pushing that to a Slack channel, or is it over email, or multiple different ways?
Nick Swan: Anything. A webhook is basically like your own API that we can HTTP POST data to. It could be any of those things. Slack supports webhooks, for example, and n8n workflows-you can kick off workflows within n8n. Anything that supports webhooks.
Jon Clark: Awesome. Last question: where should listeners go to test SEOTesting, and are there any offers for the listeners?
Nick Swan: We have a 14-day trial by default, but we've got an extended trial we can offer to listeners for 45 days. I did send through the link, which you can put in the show notes.
Jon Clark:
seotesting.com/partner/page2pod.
Nick Swan:
Get on that for the extended trial. It's me doing support quite a lot of the time, so if you use the chat widget in the bottom, you can talk directly to me and pass through any feature requests. What's funny as well-sorry, just going back to another thing-we have a "Suggest a Feature." I copied this from someone else where we pop up a little thing and ask people to write the prompt as though they were going to build it themselves. Occasionally we've been able to take someone else's prompt and use that within Claude Code itself directly. So yeah, I'll be on support. Feel free to ask me questions.
Jon Clark: Incredible, that's brilliant. Well, Nick, this has been great. I'm really happy that we were able to make this work-a perfect episode to wrap up the season. Thanks again for joining us on the Page 2 Podcast. For those listening, if you enjoyed the show, please remember to subscribe, rate, and review. We'll see you next time. Bye-bye.