User manual

Moks CMS runs the whole publication from one admin: writing and publishing, search and audience data, AI drafting, comments and enquiries, site design and operations.

The sidebar groups pages by category (Overview, Content, Editorial & AI, Insights, Community, Site settings, Operations, Account). Each category expands and collapses, and the browser remembers your choice. A collapsed category still shows the total of its badges (pending reviews, unread messages, comments to moderate), so nothing that needs attention is hidden.

The Dashboard greets you with the number of items that need attention across the publication.

On a phone, the Menu button at the top shows the current page and opens the same list.

• Admin: every page, every setting.
• Author: writes and publishes their own posts, manages their author profile and API keys, and moderates comments.
• Reader: a public account for commenting; no admin access.
• Demo (read-only): sees every admin page an admin sees, with real data, but cannot save, publish, delete, send or run anything, and cannot download backups. A banner at the top of each page says so.

Admins change roles in Admin → Users. A role change or ban signs the person out straight away.

A demo account shows the CMS exactly as the site owner uses it. Open any page, use filters, date ranges and search, open articles in the editor and read reports.

Anything that would change something (Save, Publish, Delete, Send, Sync, Generate, Approve) is refused with a read-only notice and nothing is stored. AI and paid external calls are never made, so exploring costs nothing.

Good places to start: Dashboard, Posts (open one in the editor), Search performance, Content audit, Review queue, Appearance & settings (look at the previews), System status and this guide's FAQ.

The manual's home lists every guide by category, the FAQ and the settings reference. The contents on the left (under Contents on a phone) list every guide and question; each opens on its own page, which has its own address to bookmark or share.

A guide's page shows where you are (User manual, the category, the guide), who the page is for, an On this page list, the text and its diagram, where the page is in the admin, the settings of that page with their defaults, related guides, and links to the previous and next page in reading order.

Print / Save as PDF on a guide prints that guide without the menus. Printable manual on the home opens the whole manual on one page, with a contents list, for printing or saving as a PDF.

Type in the search box to match titles, summaries, text and common synonyms (for example “publish”, “backup” or “password”); a suggestion opens that guide. Choose an area to narrow the list, or switch between Guides, FAQ and Settings.

Settings lists every setting and option of the CMS with what it does and its default value, from Appearance to the SEO agent, Advanced settings and MCP scopes.

Each article links to the admin page it describes. The address bar keeps your search and filters, so you can bookmark or share a view of the guide.

Demo accounts are read-only by design: you see the admin exactly as the owner does, but every save, publish, delete, send, sync and AI action is refused and nothing is stored.

Ask the site owner for an author or admin account if you need to make changes.

Yes. Demo accounts see the live publication's data, as an admin does. Secrets (keys, passwords, tokens) stay masked everywhere.

Authors only see the pages they can use: content, comments, their profile and API keys. Editorial & AI, Insights, Site settings and Operations are for admins (and read-only demo accounts).

Only if an admin turns on Appearance & settings → General → Public user manual. It then appears at /user-manual for everyone, read-only and without any of your data. It is off by default.

Posts lists every article, news item and project with its status: draft, review, published or archived. Filter and search the list, then open a post in the editor.

A post needs a title, a slug (its address), a description used for listings and search results, a category and a content type. News and curated posts also need at least one source.

Publish from the editor's own Publish button. Editorial calendar items become published only when their linked post is published this way.

Each published post has an Insights view with its search and visitor data.

Markdown is the stored format. The visual editor is a view over it, so switching between Visual and Markdown never loses anything. If a document contains something the visual editor cannot show exactly, it opens in Markdown mode and says why.

Insert blocks with + (searchable) or by typing / in an empty paragraph. Callouts, figures, galleries, buttons, embeds (YouTube and Vimeo), video, audio, details and a table of contents are available as blocks.

• Save: Ctrl/⌘ S
• Undo / redo: Ctrl/⌘ Z / Ctrl/⌘ Shift Z
• Move a block: Alt Shift ↑ / ↓
• Duplicate a block: Ctrl/⌘ Shift D
• Delete a block: Alt Shift Backspace

Images come from the media library or are uploaded by choosing, dropping or pasting. Alt text is required. The featured image can be chosen, uploaded or generated, with a focal point.

Pages are standalone pages that are not part of a feed: About, Contact, privacy policy, terms and so on. They use the same editor as posts.

Media keeps every uploaded file. Images are served in modern formats (AVIF/WebP) at the right size for each screen.

Images up to 10 MB upload through the site; video, audio and PDFs up to 200 MB upload directly to storage.

A file shows where it is used, and cannot be deleted while a post still uses it. Removing an image from a post never deletes the file.

Generate image creates a picture with AI (when it is configured in Integrations); you choose whether to keep it.

Categories are the topics that organise posts. Each has its own page and RSS feed.

Tags are free-form labels. Renaming a tag (Admin → Tags) fixes it on every post; renaming it onto an existing tag merges the two.

Python practice manages the interactive coding exercises on the public site: problems, engineering roles and topics, the daily challenge, the sandboxed code runner, the AI tutor and abuse signals.

A new problem is saved as a draft; quality checks and duplicate detection run on save, and you publish it once it validates. Every save creates a new version, and old submissions keep pointing at the version they were graded against.

Readers on /python-practice can write Python and press Run. Running a stranger's code is risky, so it never runs inside the website.

• The website checks the reader is signed in and within their limits, then sends the code and only the test inputs (never the expected answers) to the executor.
• The executor puts the job in a queue. A dispatcher starts a brand-new, throw-away sandbox for each job.
• The sandbox has no internet, no passwords and no access to anything else. It uses gVisor, a protective layer between the code and the real server. Time, memory, file size and output are all capped.
• The sandbox prints the results; the dispatcher reads them and deletes the sandbox.
• The website compares the outputs with the expected answers itself, so a cheating program cannot fake a pass. Progress, XP and badges are then given exactly once.

Repeated abuse (for example endless loops) blocks the account for 15 minutes. Admins manage problems, roles, topics, the daily challenge, the AI tutor and abuse signals under Python practice.

Open the post in Admin → Posts, fill in the required fields (title, description, category, content type; sources for news) and press Publish in the editor.

To publish later, schedule it instead. AI-drafted articles are published by approving them in the Review queue.

Yes. Markdown is the stored format; switch the editor to Markdown mode at any time and back to Visual without losing anything.

A file that is still used by a post cannot be deleted. The media library shows where it is used; remove it from those posts first.

Their code runs in a separate, throw-away sandbox with no internet and no access to the website, its database or any passwords, and with strict time and memory limits. The website grades the results itself.

Items move through Suggested → Approved → Drafting → In review → Published.

An item becomes Published only when its linked post is published with the editor's Publish button.

Claude drafts improvements and new articles; they wait here for a person. Nothing goes live until you approve an article.

Approving publishes it and submits it to search engines. The sidebar badge shows how many drafts are ready.

Jobs discover stories from trusted sources, rank them and draft news grounded in those sources. Nothing publishes without your approval.

• Sources: the feeds and official APIs the desk reads (robots.txt honoured, paywalled sites refused).
• Topics & categories: map news topics to the CMS's categories; your corrections train the classifier weekly.
• Profiles & playground: versioned writing and image styles; proposed versions need your approval.
• Run history and News analytics: every run with its cost and errors, and how published news performs.
• Settings: global spending caps on top of each job's own budget.

Promotion suggests where each published article is worth sharing, drafts posts for you to edit and post yourself, and suggests new article ideas that already have an audience. Nothing is posted automatically.

No. AI-drafted articles and news wait in the review queues until a person approves them. Assistants connected through MCP can never approve or publish.

The one automatic change is internal linking, when its weekly job is switched on, and it works within strict limits.

The news desk has global caps on top of each job's budget, and Automation & AI shows Claude usage. AI and paid calls are always explicit actions, never triggered by just viewing a page.

Automation & AI shows the search and analytics connections, Claude usage, ML models and Ask the Blog, then the settings by area. Every saved change is audit-logged.

• Data sources: which Google properties are read, how far back and how long data is kept; DataForSEO for search volume, difficulty, live rankings and backlinks.
• Schedules: when each job runs (UTC; weekday 0 = Sunday).
• Scoring & rules: the weights and thresholds that find and rank recommendations.
• Content & links: keyword opportunities, internal-linking limits and search-engine submission.
• AI & drafts: Claude drafting (always stops at human review), its monthly budget, the optional explanation model and AI visibility.
• Crawler: limits for the technical crawl of your own site. Reports: weekly and monthly report email.

Every field is listed with its default under Settings in this guide.

The SEO agent is a separate service that runs CrewAI flows. Sync flows read Google Search Console, GA4 and (optionally) DataForSEO into the database on a schedule.

Rules and ML models turn that data into recommendations, reports and alerts, and pick articles worth improving. Drafting flows (optimize_article_flow, new_article_flow) ask Claude crews for a draft within the monthly budget and the rewrite limit.

Drafts stop at “ready for review”. Only a person approving on the site starts publish_flow, which publishes and submits to search engines. Nothing in the agent, the schedules or MCP can approve.

Start a flow by hand with Run now on the relevant page; queued runs start within about 30 seconds and appear in Data sync.

The website and the seo-agent are two separate programs. The website shows pages and the admin. The seo-agent is a Python program that does the slow, background work, so the website stays fast.

• It wakes up on a timetable (for example every morning at 06:10 UTC to fetch Search Console data). Pressing Run now in the admin, or asking through MCP, starts the same job straight away.
• It fetches data from Google and DataForSEO and saves it in the same database the website uses.
• It looks at the numbers, finds pages that can do better and asks Claude to write a suggested fix.
• It saves every suggestion as a draft. It never publishes on its own.
• It also trains the ML models each week, builds reports and keeps the Ask the Blog search index up to date.

Every run is listed in Data sync with its status, what it did and any errors. If the seo-agent is down, the website keeps working; only the background jobs wait.

CrewAI is the open-source library the seo-agent uses to organise its AI work. Two ideas matter:

• A flow is a recipe: a fixed list of steps, such as “fetch the article → study the numbers → write a fix → check the fix → save the draft”. Most steps are ordinary code, not AI.
• A crew is a small team of AI helpers (agents). Each agent has one job, a short description of who it is, and a few tools. They work one after another, like an assembly line, and each passes its work to the next.

The crews on this site:

• Optimization crew (improving an existing article): an SEO analyst explains what is wrong from the search data, an editor writes the smallest useful change, and a technical reviewer checks every command and fact against official documentation.
• Editorial crew (a new article): a researcher collects sources, a technical writer writes the draft, a technical reviewer checks it, and an SEO editor suggests the title, description and headings.
• Report crew: one writer turns already-calculated numbers into a short summary. Every number it writes is checked against the real figures; one wrong number and the summary is thrown away.
• Promotion crew: a copywriter drafts social posts for an article, and a content strategist suggests new article ideas with evidence.

Safety rails: agents can only read (no publishing, no deleting, no code running), each has a limit on steps, time and tokens, every call counts against the monthly budget, and article text is treated as data, never as instructions. When a crew finishes, the flow checks its output and saves a draft. Only a person approving in the Review queue can publish it.

Every Sunday the seo-agent runs the ML job. For each model it does the same four things: learn from your past data, test itself on data it has not seen, compare its score with the simple rule the site used before, and save the result. The website only reads the saved results; no ML runs while someone loads a page.

• Falling pages (content decay): looks at each page's daily clicks, removes the normal weekly ups and downs (and yearly seasons when there is enough history), and flags a page only when its trend has fallen steadily for three weeks and clearly more than usual. In tests it raised far fewer false alarms than the old 28-day rule.
• Topic groups (query clusters): turns each search query into numbers that capture its meaning (embeddings) and groups queries that mean the same thing. You check a sample of groupings on the Labelling page; the model is used only when it matches your answers better than simple word matching.
• Search intent: learns from intent labels Claude gave earlier (and your corrections) to tell “how to”, “what is”, comparison and other searches apart by itself, so fewer Claude calls are needed. It is used only when it is accurate enough on your spot checks.
• Priority: looks at recommendations you already carried out and how many clicks they gained, and proposes better scoring weights. Proposals are never applied automatically; you decide.
• Related articles: mixes how similar two articles are, which search queries they share and which pages readers actually visit together, and picks the best six for each article. Clicks on the related block (with consent) measure whether it works.

If a model is not better, too new or more than 14 days old, the site quietly uses the rule, and every number says which one made it.

The SEO agent trains five models each week: content decay (seasonal trend decomposition), query clusters (embeddings and HDBSCAN), a search-intent classifier, learned recommendation priority, and related articles. No ML runs inside a web request; the site reads the stored results.

A new version becomes active only if it beats the current rule on held-out data (and, for some models, after your review). Its output counts as fresh for 14 days.

• Override auto (default): the model when an active version is fresh, otherwise the rule.
• Override rule: always the rule.
• Override model: the model whenever its output is fresh, even if it never beat the rule.

Every number on the site says where it came from: model vN, rule, rule (insufficient history) or rule (stale model output). Labels lets you review training labels; Run now trains outside the schedule.

Two MCP servers expose the platform to AI assistants. The admin server needs OAuth 2.1 with PKCE; the public server is read-only and serves published articles only, without sign-in. Each has a kill switch (ADMIN_MCP_ENABLED, PUBLIC_MCP_ENABLED) and the page shows whether it is on.

To connect Claude: in Claude, Settings → Connectors → Add custom connector with the admin server URL shown on the page. Claude registers itself, sends you to a consent page on this site, and then appears under Connected clients.

• seo:read: read SEO metrics, keyword opportunities, the review queue, draft diffs, audit issues, flow runs and LLM usage.
• seo:flows: start drafting, sync, audit and report flows (drafts still wait for your approval on the site).
• seo:review:reject: reject drafts and add review notes.

No scope can approve, publish, roll back or submit to search engines. Connected clients shows each client's scopes, who allowed it and when it was last used; Revoke ends its access at once.

Claude drafts and classifies for the SEO agent (the models are set under Automation & AI → AI & drafts; empty uses the deployment's defaults). Gemini generates images when configured in Integrations. AI visibility asks the assistants you switch on.

Yes. Set its override to rule on the ML models page; the site then always uses the rule. auto (the default) only uses a model that beat the rule on held-out data and is less than 14 days old.

Admin → MCP access → Revoke on its row. The token stops working at once. To switch the whole admin MCP server off, the operator sets ADMIN_MCP_ENABLED=false.

Drafting stops at the monthly budget in Automation & AI → AI & drafts (0 uses the deployment's ceiling, by default $15). DataForSEO and AI visibility have their own monthly caps; a run stops before a call that would cross one.

An agent is one AI helper with one job (for example “editor” or “technical reviewer”). A crew is a small team of agents that work one after another on the same task. A flow is the step-by-step recipe that runs the crew and saves its draft.

The model was not used because it has not yet proven better than the rule, does not have enough history for that page, or its results are more than 14 days old. The rule is the safe default.

The website keeps working. Background jobs (syncs, drafts, reports, ML) wait until it is back; Data sync and System status show the problem.

Search performance shows Google Search Console data for a period, compared with the previous one. Change the date range and search type to explore.

Data arrives through Data sync; if numbers look stale, check the latest run there.

Visitor analytics shows Google Analytics 4 data for the chosen period.

Page insights lists every page with Search Console data, joined with its GA4 landing-page sessions and the CMS article, so you can see which articles bring search visitors.

Keyword opportunities come from your Search Console data (anonymised queries are not included, so totals are partial). Search volume and keyword difficulty come from DataForSEO when it is configured. Track the keywords you care about.

Recommendations are rule-based, evidence-backed suggestions. Scores are priorities, not forecasts. Approving records your decision; nothing is changed on the site. AI explanations are labelled and should be verified.

Content audit lists every published article, weakest first. Hover, tap or focus a number to see the issues behind it.

Technical health is a weekly polite crawl of the public site: robots.txt, sitemaps, status codes, redirects, canonicals, titles, meta descriptions, headings, alt text, structured data, broken links, orphan pages and more.

Internal linking shows how articles link to each other. A weekly job can add links on its own within strict limits; other link changes are reviewed as drafts.

Backlinks lists sites linking to this one, from DataForSEO's weekly snapshot. It is DataForSEO's crawl, not Google's, so counts differ from Search Console.

Each week a set of prompts is asked to the enabled AI assistants with web search on. A prompt counts as cited when an answer links to the site, and mentioned when it names it.

These are API answers; the consumer apps can differ, so read them as a trend. Open a prompt to see the stored answers.

Weekly (last full Monday–Sunday) and monthly (last full month) reports, compared with the previous period. Export as CSV, open a printable page, or download a designed PDF when one has been generated.

Search Console data is usually two to three days behind. Check Admin → Data sync for the latest run and its errors; queued runs start within about 30 seconds.

Backlinks come from DataForSEO's own crawl, not Google's, so their counts differ. Read both as trends.

Comments shows new and reported comments for review, and lets you open, lock or close the discussion on each post. The sidebar badge counts what is waiting.

Every decision is recorded in the audit log. Comment text is shown as plain text, so nothing in a comment runs in the admin.

• Messages: contact-form messages and Hire me enquiries. The badge counts unread ones.
• Bookings: meetings booked through Cal.com from the Hire me page. Reschedule or cancel them in Cal.com.
• Payments: paid calls from the Hire me page (Razorpay). Refunds and settlements are handled in the Razorpay dashboard.

The Hire me page itself is configured under Appearance & settings.

Change the public site without code: general details, branding (logos, favicon, share image), header, navigation menus, footer, typography and colours (with live contrast ratios), the homepage sections, blog listings and the Hire me page.

Changes go into a private draft that you preview on the real pages, then publish explicitly. History lets you roll back, and settings can be exported and imported.

General settings also turn comments, reader sign-up, the contact form, the public user guide and maintenance mode on or off.

Integrations connects the site to outside services. Secrets are encrypted at rest and never shown again; leave a secret field empty to keep the stored value.

• Social sign-in (Google, GitHub): register the callback URL shown on the page exactly as given with the provider, then paste the client ID and client secret. Each provider can be switched on or off.
• IndexNow: tells Bing and other IndexNow search engines about new and changed pages straight away. The key file is served by the site so search engines can confirm it belongs to you.
• Image generation (Google Gemini): the API key, the Fast image model used by default in the editor, an optional Pro model (better, slower, dearer), the default image size and the largest size authors may pick (caps cost).

Analytics, ads and search-engine verification tokens are under Advanced settings; Search Console, GA4 and DataForSEO connections are under Automation & AI.

Keys are encrypted at rest and never shown again; leave a secret field empty to keep the stored value.

• Media storage (Cloudflare R2): account ID, bucket, an access key ID and secret scoped to that bucket, an optional public media URL (a custom domain for large files) and an optional API endpoint for EU/FedRAMP buckets. A one-time tool moves existing media from S3 to R2.
• Email: choose one provider (SMTP, Mailgun or Amazon SES; there is no automatic failover), the sender name and address and an optional reply-to. SMTP needs host, port (587 STARTTLS, 465 TLS), encryption and credentials; Mailgun a sending domain, region and API key; SES a region and either the server's AWS credentials or access keys stored here. Send a test before relying on it.

Email is needed for sign-up verification, password resets and demo invitations.

• Invite demo users: enter an email; the person gets a link to choose a password (valid 72 hours, Resend invite sends a new one). Needs email set up.
• Add a user with a password: create an account of any role with a password you choose. No email is sent; share the password yourself.
• Change a role in the table and press Save; the person is signed out so the new role applies at once.
• Ban signs a user out and blocks sign-in; Delete removes the account (not possible while they still own posts).

Advanced settings holds lower-level site options. Change these only when you know what a setting does; each page section explains its options.

Admin → Users. Either invite a demo user by email (they choose their own password), or use “Add a user with a password” to create an account of any role with a password you set and share yourself.

Press Resend invite on that user's row in Admin → Users for a new 72-hour link, or the person can use Forgot password on the sign-in page.

Ban the account, delete it, or change its role in Admin → Users. Each of these signs the person out immediately.

Check Admin → Storage & email: outgoing email must be configured. Then check System status for a failing email check, and ask the person to look in their spam folder.

Yes. Appearance & settings keeps a history; roll back to the previous version.

The callback URL registered with Google must match the one shown in Admin → Integrations exactly, including https and the path.

System status runs live checks of every service the site depends on; reload the page to run them again.

Data sync lists every scheduled, manual and backfill run: window, status, rows written, Google API requests, retries and errors. Queued runs start within about 30 seconds.

ML models shows the models trained weekly; a model is only used when it beats its rule on held-out data.

Create zip backups of content and configuration, encrypted if you choose. Backups exclude password hashes, sessions, API-key hashes and stored credentials.

Restore replaces posts, pages, categories, comments, media records, redirects and Appearance settings with a stored backup, after saving the current state as a new backup. A post or category that is also in the backup is updated in place, so its SEO drafts, audits and news topics stay. An account the site no longer has is recreated as a reader without a password, whatever role it had in the backup: give staff their roles back in Users.

Demo accounts cannot download backups.

See the database connection, table sizes and maintenance tasks, and browse tables read-only. Passwords, tokens and secret settings are always redacted.

Every change made from the admin or the API, and every sign-in (successful, failed, rate-limited or blocked by the bot check), with the client IP and browser. Filter it to find who changed what and when.

Admin → Audit log records every change made from the admin or the API, and every sign-in, with the person, time, IP and browser.

No. Backups exclude password hashes, sessions, API-key hashes and stored credentials. Choose encryption when you create one if it will leave your machine.

Admin → System status runs live checks of every dependency. Then check Data sync for failed runs and the Audit log for recent changes.

Your author profile is the public page shown on your posts (at /authors/your-slug). Create it if you do not have one, and keep the bio and links up to date.

Create API keys to manage posts from scripts and automations. A key acts with its owner's permissions; revoke one you no longer need. Demo accounts cannot create keys.

Yes. Create an API key in Admin → API keys; it acts with your permissions.