Mojo Dojo has moved its website to the Hatamoto CMS
Mojo Dojo now runs on Hatamoto, an open-source content management system built in Go. Every page on this site, from our Australian SEO services to our city pages, our playbooks and this blog, is served by it.
We moved because wordpress ecosystem was prone to maintainance issues often site compromises, and because Hatamoto does the jobs a search-led business site needs without a pile of add-ons.
Here is a simple comparision for wordpress vs hatamoto.
We had outgrown our own custom platform
For most of 2026 mojodojo.io ran on a wordpress system + custom features we wrote and maintained ourselves. It did a lot. It also carried a LinkedIn sync, a Pipedrive connector, an email nurture sequence, a quiz wizard, a report builder and a separate booking tool, each with its own code to keep alive.
Most business websites look like that after a few years, whatever they run on. On WordPress it happens through plugins. On a custom build it happens through code only one or two people understand.
We wanted the opposite. A core that does the common jobs well, one place to change them, and a small, specific layer for the parts that are truly ours. On Hatamoto that layer is our theme and a handful of site-specific plugins, mainly for our city pages, our own content types and our public AI crawler index. The locales, site graph, redirects, forms, AI analytics and internal linking described below all come from the core.
SEO implications
The fear with any platform move is lost rankings. Old addresses break, redirects go missing, and months of search equity drain away. We set a strict test before we switched. Every address in our sitemap, had to return the same status and land on the same final path as before. All 820 of our existing redirects had to behave the same way. And there could be no new 404 errors.
Hatamoto made that test practical because addresses are data, not code. Each content type has its own address pattern, so our blog stays at /blog, case studies stay at /case-studies, and service pages stay under their country folder. Nothing had to be rewritten to fit the CMS.
If you are coming from WordPress, there is a built-in import that reads your site and keeps your old addresses working. It produces a URL audit so you can see what moved before you switch over. There is also a site setting that answers the old WordPress address families, such as dated permalinks, author pages, category and tag archives and feed addresses, with redirects to the right place. It stays off unless you turn it on.
Five countries run from one site with locales
Mojo Dojo serves businesses in Australia, the United States, the United Kingdom, New Zealand and Singapore. Each country has its own service pages and city pages. Getting that right for search is fiddly. Google needs to know which page is meant for which country, which pages are copies of each other, and which one to show everyone else.
Hatamoto treats locales as a core concept rather than a folder naming habit. Each page belongs to a locale and to a translation group, so the CMS knows our Australian SEO page and our UK SEO page are versions of the same thing. From that it does three jobs automatically.
Every page in a group carries hreflang tags pointing at its siblings, plus an x-default for everyone else.
The sitemap splits into one set of files per locale, and each address that has copies in other locales lists them as alternates.
Each locale can have its own business details, including address, phone, opening hours and the area it serves, which feed the structured data on that locale's pages.
That last point is easy to miss. On a site with several locales, a page in a country where you have an office describes a local business with its own address, linked back to the parent organisation. A locale with no office simply says so, and the site never copies your head office address into it. Search engines get an accurate picture of where you actually operate.
If your site already uses page trees for regions, with a top-level page per country and everything below it, Hatamoto has a converter for that. It suggests a plan, runs a dry run that writes nothing, shows you a report of every change and conflict, and refuses to apply if any address would change. It can also undo a conversion.
Schema is built from the content you already have
Structured data, the JSON-LD block that tells search engines and AI assistants what a page is about, is where many business sites fall down. It is usually bolted on through a plugin or left half-finished. Hatamoto builds it on the server from the content itself and your site settings.
Every public page carries up to four blocks. There is a document for the page itself, such as an Article for a post with its headline, author and dates. If the page has FAQ items, a FAQPage with each question and answer is added next to it. Pages with breadcrumbs get a BreadcrumbList. Archive pages such as the blog index get a CollectionPage. And every page includes the site graph, an Organization and a WebSite node tied together, built from your business details.
The site graph goes further than most tools we have used. You can fill in your legal name, tax ID, identifier codes such as your industry classification, founders, awards, memberships, the topics you know about, and booking or ordering actions. You can also publish a catalogue of your services. Every page on our site, including our Australian SEO services page, lists each of our services with its offer and price range, because we entered them once in the business details settings.
Nobody on our team writes JSON-LD by hand any more. When we change a price, add an FAQ or update a phone number, the structured data follows, and a built-in checker tests each page's output.
Rich results, local listings and AI assistants all lean on structured data to understand who you are and what you sell. Accurate markup on every page, by default, gives search engines and AI tools a clearer picture of your business.
AI analytics shows which assistants read your pages
This is the feature we would find hardest to give up. Search is no longer only Google and Bing. OpenAI, Anthropic, Perplexity and others send crawlers to read your pages, and some of them send people back to you. Most analytics tools see none of this, because AI crawlers do not run the tracking scripts those tools depend on.
Hatamoto renders every page itself, so it sees every request and its real user agent. It records each visit from a known AI crawler or assistant, which company runs it, what the visit was for, the response it got and which page it fetched. It keeps a registry of 43 known agents and sorts them by purpose.
Training crawlers collect content for model training, such as GPTBot and ClaudeBot.
Search index crawlers build an AI search index, such as OAI-SearchBot and PerplexityBot.
User fetchers read a page because someone asked an assistant a question, such as ChatGPT-User.
Classic search engines, social link previews, SEO tools and web archives are tracked separately so they do not muddy the AI numbers.
Anyone can put "GPTBot" in a user agent, so a visit is checked against the IP ranges the AI companies publish. The admin shows which visits were verified and which were pretending. It also flags the agents known to ignore robots.txt.
The referrals view counts people who clicked through to your site from an AI assistant, per assistant, per day. It does that without cookies, without a visitor identifier and without storing which page they landed on. Nothing leaves your server.
From the same screen you can allow or block AI crawlers by purpose. If you want ChatGPT to be able to fetch your pages when a customer asks about you, but you do not want your content used for training, that is one switch rather than a robots.txt edit you hope is right. The site also publishes an llms.txt file, a short index of your content written for AI tools, which updates itself as you publish.
We can see which of our service pages AI crawlers read, which they skip, which errors they hit, and whether that reading turns into visitors. Any business that wants to show up in AI answers needs those numbers.
Forms and leads live inside the CMS
On most sites, forms are a plugin with a licence, a separate settings area and its own idea of where submissions go. In Hatamoto they are part of the admin. You build a form by adding fields, mark the required ones, set a success message and choose who gets the email notification. Then you place the form on a page with the page builder.
Submissions are stored and listed in the admin, can be handled in bulk and export to CSV. Spam protection is built in. Messages caught by the spam rules are kept with a Spam status rather than deleted, so a real enquiry that was caught by mistake can be moved back.
Our strategy session booking used to be a separate plugin. On Hatamoto it is a standard form with a date field and a time slot picker, on the same address as before. Webhooks are built in too, so a CRM or messaging tool can be told about each new submission and fetch it through the API, without another plugin.
Redirects are fast to manage and safe by default
Redirects seem simple until a site has hundreds of them. Ours has more than 800. Hatamoto gives them a proper admin screen with a few details that make a real difference.
Wildcard rules. One rule can send an entire old section to a new one, carrying the rest of the path across.
Clear precedence. An exact rule always beats a wildcard, and among wildcards the more specific one wins. Rules that would catch the whole site are rejected.
Explain a URL. Type in an address and the admin shows every rule it checked and which one won.
A 404 log, so you can see broken addresses people and crawlers are actually hitting and fix them.
Instant effect. Redirects are checked before the page cache, so a new rule works the moment you save it.
The part we value most is what happens without anyone touching the redirects screen. When you change the slug or the parent of a published page, Hatamoto adds a 301 from the old address to the new one, for that page and every page below it. Older rules that pointed at the old address are repointed, so visitors never follow a chain of redirects. If a page is later published at an address that a redirect is holding, the automatic redirect steps aside so the page wins. Rules you wrote yourself are never changed.
Internal linking runs on rules, not guesswork
Internal links tell search engines which pages matter and how your topics connect. Added by hand, they are slow, easy to forget and break when a page moves.
Hatamoto has a linking module in the core. It works from a catalogue of rules: a phrase, the page it should point at, and a priority. Our catalogue maps phrases such as Core Web Vitals, Merchant Center and AI search to the service pages and guides that cover them. For any page, the module suggests where those phrases appear and which links can be added. An editor can accept them one at a time, or a script can apply them through the API.
When a link is inserted, the server wraps the exact phrase, tags the link with the target page's ID and updates a link index. That index is the clever part. Every link the module inserts knows which page it points to, so a change to that page's address rewrites those links across the site. Links inserted this way do not go stale when a page moves.
The index also feeds an equity dashboard. For every page it shows how many internal links point at it and from where. Pages you consider important but which have few inbound links stand out straight away, and you can drill into the list of pages linking to any target.
This blog shows it in practice. When a news post is written, the linking module adds links from our rules before the post goes live. The links follow sensible limits, with one per target, one per phrase and a cap on how many a post can carry, so they read like links a person chose. Our long-form guides get the same treatment. On WordPress we would need a separate internal linking plugin to get close.
The rest comes in the box
A good deal more comes with the core.
A page cache that clears itself on every edit, so repeat visits load in a few milliseconds and nobody has to remember to purge it.
SEO titles and descriptions, sitemaps and feeds, with no SEO plugin.
Custom content types set up in the admin without code. Our services, case studies, industries, playbooks and glossary terms are all content types.
Visitor analytics with no cookies, showing visits by channel, source, campaign, landing page, device and country, without storing IP addresses or visitor IDs.
An MCP server, so AI tools such as Claude can draft and publish content through the CMS using a key you control and can revoke.
Plugins and themes that run in a sandbox with only the permissions you approve, designed so a faulty plugin cannot read your users or bring the site down. Themes are trusted code, so install them only from sources you trust.
Signed releases and automatic updates you control, with every outbound connection the server makes listed in the docs alongside a switch to turn it off.
No telemetry unless you opt in.
Under the hood it is one Go program and a Postgres database. There is no PHP, no Node and no stack of separate services to keep in step. It is open source under the Apache 2.0 licence, so you can read every line and are not tied to one vendor. Everything is on hatamoto.dev.
Eleven WordPress plugins become one install
WordPress deserves respect. It powers a huge share of the web and its ecosystem is enormous. But a typical WordPress business site that wants to do well in search ends up with a stack of plugins, and every one adds a renewal, a round of update testing and more attack surface.
Hatamoto's own comparison with WordPress lists 11 common plugins it replaces.
SEO, usually Yoast or Rank Math
Caching, usually WP Rocket or W3 Total Cache
Forms, usually Gravity Forms or WPForms
Redirects, usually Redirection
Analytics, usually Site Kit or Jetpack
Custom fields, usually ACF or Pods
Two-factor login, usually Wordfence or Two Factor
Backups, usually UpdraftPlus
Internal links, usually Link Whisper
Webhooks, usually WP Webhooks
An llms.txt plugin
Then there is the work WordPress cannot do at all out of the box. It has no AI crawler reports and no per-purpose controls for AI crawlers. Schema depends on whichever SEO plugin you chose and how carefully it was set up. And plugins run with full access to your database and files, so a single bad plugin can expose a whole site.
That is why we say Hatamoto is better than WordPress for a business site that depends on search. You usually get a faster site out of the box, cleaner structured data, visibility into AI search and fewer moving parts to pay for, update and secure.
Why we rate it above the rest of the market
WordPress is not the only alternative, so it is fair to ask how Hatamoto compares with the rest, from hosted website builders to headless CMS products. Each does some things well. Many hosted builders are easy to start with but give you limited control over addresses, structured data or redirects at scale. Headless platforms are flexible, but you usually pay developers to build the website half yourself, including the SEO features Hatamoto ships with.
We do not know of another platform that combines locale-aware structured data, server-side AI crawler analytics with verification, a rules-based internal linking engine with a link index, and automatic redirect handling in one open-source core you can host yourself. For the kind of site our clients run, a business that wins work through search and now through AI answers, Hatamoto is the strongest option we have found.
The closest rival we have looked at is EmDash, a newer open-source CMS that also ships an MCP server and sandboxed plugins. Hatamoto's comparison with EmDash is candid about the trade. EmDash works best on Cloudflare and supports more languages and staff roles. Hatamoto comes out ahead on AI crawler reports, schema, forms and updates that install themselves, and it gives you the same plugin limits on any server you choose. For a business site that lives on search, those are the lines that count.
When we would tell a client to stay put
We would rather you choose well than move and wish you hadn't, and Hatamoto is not for everyone yet. Stay where you are if any of these apply.
You sell online. There is no equivalent to WooCommerce or Shopify.
You run memberships, paywalls or public comments.
Your site is published in several languages.
You run a network of sites from a single install.
You need budget shared hosting or a host with one-click installs. Hatamoto runs on your own server, a VPS or a container host.
You depend on a particular plugin or theme, or need a large pool of developers who already know the platform.
You run very high traffic. Hatamoto supports several servers, but that setup has not yet been proven at the scale of the largest WordPress sites.
Hatamoto 1.0 is also still rolling out through its early release channels, and its plugin SDK is still at version 0, so the plugin interface and some APIs can still change between versions. It already runs real sites in production, including this one.
Trying Hatamoto takes an afternoon
If the list above does not rule you out, we would urge you to try it. You do not have to move your live site to find out whether it suits you.
Hatamoto installs as a single program pointed at a Postgres database, or with one Docker command that starts the database too. The project says a basic install takes about ten minutes. Once it is running, the admin walks you through first setup, and the docs on hatamoto.dev cover every screen.
Then import a copy of your current site. If you are on WordPress, run the import, read the URL audit, and look at three things: the structured data on a service page, the internal link suggestions for your most important pages, and the AI crawler report after a few days. Those three will tell you more than any comparison table.
If you would like a hand, talk to us. We have moved our own site of more than a thousand pages across five countries without losing an address, and we are happy to look at whether yours would benefit from the same move.