AI/GEO Implementation Report

Smart Bulk Payments - 3P Smart LTD

Prepared for: Paola Fernández, Chief of Operations Officer, 3P Smart LTD
Prepared by: dimartec
Report version: 1.0
Report date: 6 August 2026
Period covered: 16 June 2026 – 6 August 2026

How to use this document

This report is a single technical reference combining two things that were previously split between the Client Portal and the Tasks/Instructions spreadsheet:

• Part One - The AI/GEO Implementation Framework. The rules that govern any change to the website. This part is written to outlive the project: it applies to any page, section or rebuild, now or in two years.
• Part Two - Application to Smart Bulk Payments. What the June 2026 audit found, what changed, where, why, and what each change is expected to do.

The appendices hold the exact technical artefacts now in place – the robots.txt file, the llms.txt file, every JSON-LD block, the published FAQ content, the About page text and the meta descriptions.

Executive summary

In June 2026 the technical foundations of the site were strong – fully server-rendered content, valid structured data on every page, clean sitemaps, and an llms.txt file that most competitors still do not publish. That foundation was being undermined by one dominant problem: the business presented itself under at least six competing identities across its web estate, including legacy "Pilsenga" content belonging to a different legal entity. Overall GEO readiness scored approximately 5.0 / 10.

This matters because generative engines answer questions about entities. Before a model will name and cite a company, it assembles an internal profile by corroborating signals across the website and the wider web. Six names means six weak signals instead of one strong one – and low confidence means low citation.

Between June and August 2026, 27 tracked tasks plus a 16-point entity naming checklist were completed. The work fell into five groups: Smart Bulk Payments was consolidated onto smartbulkpayments.com as its canonical home, with page-to-page redirects preserving accumulated authority; every naming variant was resolved to a single entity name and all legacy Pilsenga content removed; a dedicated About page was published as the canonical answer to who the company is and what it does; the commercial offering was made machine-readable through Service, Offer and FAQPage schema across six pages, totalling 35 question-and-answer pairs; and the discovery layer was cleaned – an explicit AI-crawler policy naming 11 bots, a hand-curated llms.txt, a pruned sitemap, repaired internal links and corrected page language.

The estate now presents one name, one canonical home, one machine-readable description of what the business does and who it serves, and one authoritative brief for language models. That is the precondition for citation. Section 12 sets out the specific questions and prompts the site is now positioned to answer.

PART ONE - THE AI/GEO IMPLEMENTATION FRAMEWORK

Use this guide whenever adding a page, creating a new website section, publishing content, changing the design, or rebuilding the site.

The website now has a strong GEO foundation. The purpose of this guide is to make sure future changes preserve it.

GEO is a new and fast-moving discipline. LLM providers and search indexes continually change how they discover, interpret and evaluate web content, so these checks represent current best practice rather than a permanent standard.

1. The three rules to follow for every change

Rule 1 - Keep the company identity consistent

• Use the same canonical brand name, legal name, company description, product names, contact details, social profiles and licensing information everywhere.
• Make sure visible content, page titles, metadata, structured data, the About page and llms.txt all describe the same organization.
• Do not publish old brand names, legacy company details, placeholder copy or conflicting descriptions.

This is the most important rule. Conflicting entity information makes it harder for AI systems to determine who the company is and which claims, products and pages belong to it.

Rule 2 - Make the page understandable to machines

• Put the important explanation in visible, server-rendered text - not only in images, videos, animations or JavaScript interactions.
• State clearly what the page is about, which service or product it covers, who it is for, and how it relates to the company.
• Add valid, appropriate JSON-LD structured data, and ensure it agrees with the visible page content.
• Give the page one clear title, meta description, canonical URL, language declaration and H1.

Clear content and structured data help AI systems associate the brand with the correct facts. If the content is included in future model training, it can also improve the chance that future models learn and recognize the brand without needing a web search.

Rule 3 - Make the page easy to discover

• Link to the new page from at least one relevant existing page, using descriptive anchor text.
• Link from the new page to its parent section, related services, useful supporting content and the canonical About page where appropriate.
• Add important pages to the main navigation or footer when they belong there.
• Include the page in the XML sitemap and, if it is authoritative, in the curated llms.txt file.
• Confirm that robots.txt and page-level robots directives do not block it.

A page that is technically live but isolated from the rest of the site is harder for crawlers and AI systems to discover, contextualize and trust.

2. When adding a new page

Before publishing, confirm that:

• The page uses the approved company and product names.
• Its core information appears in the initial HTML response.
• It has a unique title, meta description, canonical URL, H1 and correct language declaration.
• It includes only relevant and valid structured data.
• It has at least one useful internal link pointing to it, and useful links back into the site.
• It does not duplicate or contradict an existing page.
• It is crawlable and included in the appropriate sitemap.
• llms.txt is updated if the page should be treated as an authoritative company resource.

3. When adding a new section, blog, subdomain or separate website

• Use the same brand identity, visual identity, company description and Organization schema as the main website.
• Do not allow the new section to appear to be a separate company unless it genuinely is one.
• Connect it to the main site with clear navigation and contextual internal links in both directions.
• Give the section a clear purpose and hierarchy; avoid creating several pages that compete to explain the same subject.
• Keep legal, regulatory, contact and product information synchronized across every site or subdomain.
• If publishing multiple languages, use dedicated language URLs and correct hreflang annotations; do not mix languages unintentionally on one page.

4. When redesigning, migrating or replacing the website

• Preserve the canonical About page and the approved company facts it contains.
• Preserve or correctly replace existing metadata, structured data, internal links, sitemaps and crawler rules.
• Keep important content server-rendered and available without requiring user interaction.
• Redirect retired URLs to the closest relevant replacement; do not leave duplicate, legacy or conflicting pages live.
• Recheck navigation, footer links, calls to action and cross-links so none point to empty anchors or missing pages.
• Review the rendered website - not only the CMS fields or design files - before launch.

5. Final pre-launch check

Before any meaningful website change goes live, answer yes to all five questions:

1. Does this change describe the same company, products and facts as the rest of the website?
2. Can a crawler understand the important content directly from the delivered page?
3. Do the metadata and structured data accurately match the visible content?
4. Can the page be discovered through normal internal links and the appropriate sitemap?
5. Have we removed or redirected any duplicate, outdated, conflicting or placeholder content introduced by the change?

If any answer is no, the change should be corrected before publication.

PART TWO - APPLICATION TO SMART BULK PAYMENTS

6. Timeline

Audit performed: 16 June 2026
Implementation period: 25 June 2026 – 6 August 2026

7. Baseline - what the June 2026 audit found

Overall GEO readiness at baseline: approximately 5.0 / 10 - "solid foundations, undermined by fragmentation and shallow optimization."

Page speed was also scored at audit (4 / 10) and remediated. It sits outside this framework; the work carried out is recorded in Section 10.10.

The dominant finding. The estate presented the business under at least six competing identities:

The Pilsenga content was the most serious of these, because "UAB Pilsenga" is a Lithuanian-registered entity distinct from the Anjouan-licensed entity the business now presents as. On a regulated financial site that is an entity-resolution problem and a trust problem simultaneously.

The compounding finding. There was no About or Company page anywhere in the estate. The site inventory consisted of a marketing homepage, use-case pages, a pricing page and contact/sign-up flows - but no single page stating in plain prose who the company is, what it does, who it serves and under what licence. That is precisely the page a generative engine looks for when asked a company-level question.

8. The canonical domain decision

The most consequential decision in this programme was taken in late June 2026, and the reasoning is worth recording because it shapes everything downstream.

The context. At audit, the Smart Bulk Payments product lived at bulkpayments.3psmartltd.com, a subdomain of the corporate website. A well-founded SEO objection was raised against moving it: a new domain starts from zero, redirects do not transfer accumulated value perfectly, and a new property could end up competing with the existing one for the same audience. The alternative proposed was to keep everything on the existing domain and build any new sections as subfolders.

The decision. The underlying SEO logic – consolidate authority onto a single domain, avoid duplicate websites – was accepted. A different conclusion was reached for the primary domain, because the objective here is GEO rather than SEO.

Traditional SEO is largely about maximizing the authority of a domain so that it ranks in a list of results. GEO is about maximizing the clarity and authority of an entity so that an AI system understands it, trusts it and cites it inside an answer. In SEO, running several domains that each rank for something is a defensible strategy. In GEO it is a liability, because every additional property representing the same product introduces ambiguity – and ambiguity is what stops a model from citing you.

For Smart Bulk Payments to be cited, the brand needs a single canonical home, and that home must carry the brand's name. At audit, the answer to "What is Smart Bulk Payments?" was spread across multiple domains and WordPress installs. Even a human visitor could not immediately tell which site represented the product and which represented the company.

The resulting structure:

• smartbulkpayments.com - the product website, and the authoritative source for everything related to the Smart Bulk Payments brand. Every citation, mention, backlink, piece of structured data and supporting asset reinforces this single entity.
• 3psmartltd.com - the corporate website for 3P Smart LTD. It may mention and link to Smart Bulk Payments.
• bulkpayments.3psmartltd.com - retired, with permanent page-to-page 301 redirects to the corresponding pages on smartbulkpayments.com.
• trade-venezuela.3psmartltd.com, 3psmartca.com, providerpaymentplatform.com - each retained with a distinct purpose and explicitly not linked to smartbulkpayments.com, so they do not dilute or confuse the primary entity.

On the trade-off. Short-term reindexing cost is real. It is also small relative to the long-term value of establishing the correct canonical domain, and it only grows the longer the decision is deferred. Making the transition in year one is far less disruptive than making it after years of accumulated authority, citations and content.

On the review domains. smartbulkpayments.review and smartbulkpaymentsreviews.com were secured alongside the primary domain. No one can currently prove that review domains are a meaningful GEO signal, and the recommendation was not made on that basis. It was a risk/reward calculation: the cost is negligible, implementation takes minutes, and the domains simply redirect to the /reviews section of the primary site. LLM bots do search for "[brand] reviews" when handling bottom-of-funnel evaluation queries, and the downside of not holding the asset is larger than the cost of holding it.

9. How to read the implementation record

Section 10 records the work by theme rather than by task number, so that each change sits next to the principle it serves. Each entry states:

• Finding - what the audit identified.
• What changed - the change itself.
• Where - the location in the stack.
• Why - why it matters for AI visibility.
• Expected impact - what the change is intended to produce.
• Reference - the task number in the register (Section 11) and the appendix holding the exact artefact.

10. Implementation record

10.1 Entity and brand consistency

This was the critical finding and received the largest share of the work.

10.1.1 Removal of all legacy Pilsenga content (Task 1)

• Finding. Legacy "Pilsenga" and "UAB Pilsenga" content was live across the estate: the Privacy Policy, the Terms of Use page ("PILSENGA USER AGREEMENT"), the Payment Processor page copy, and entries in the auto-generated llms.txt.
• What changed. A systematic scan of the full estate was carried out and every Pilsenga reference removed. Confirmed clear on 3 July 2026.
• Where. Visible content, hidden content, WordPress fields and the hosting layer.
• Why. A model reading a Privacy Policy headed with a different company's legal name and registration number has direct textual evidence that the site belongs to a different entity. This is the strongest possible contradictory signal, and it sat on the pages models weight most heavily for company facts.
• Expected impact. Removes the single most damaging contradiction in the entity profile, and removes a regulatory-accuracy exposure on a financial services site.

10.1.2 Single entity name applied estate-wide (Task 10, plus the 16-point name-fix checklist)

• Finding. Six competing naming variants, with the JSON-LD graph contradicting itself: Organization.name read "3PSmartLTD" while WebSite.name read "Smart Bulk Payments".
• What changed. "Smart Bulk Payments" adopted as the exclusive entity name on smartbulkpayments.com. The only exception is the Privacy Policy and other legal pages, where it is stated that Smart Bulk Payments is the trading name and proprietary platform of 3P Smart LTD. A 16-point checklist was worked through systematically.
• Where. Schema, page titles, Open Graph tags, logo alt text, footer, social handles and blog branding. Full before-and-after values at Appendix A.
• Why. Rule 1 of the framework. Entity resolution is a corroboration exercise; every location that names the company is a vote, and the votes need to agree.
• Expected impact. A single, consistent entity signal across every machine-readable surface, raising the confidence with which a model can attribute claims, products and pages to this business.

10.1.3 Two "Payroll" / "Payment" corrections (Tasks 26 and 27)

• Finding. Two site-wide descriptions used the word "Payroll" where "Payment" was intended.
• What changed. og:site_name changed from "Smart Bulk Payments | Fast, Compliant Bulk Payroll Infrastructure" to "Smart Bulk Payments | Fast, Compliant Bulk Payment Infrastructure". Organization.description changed from "Fast, Compliant Bulk Payroll Infrastructure" to "Fast, Compliant Bulk Payment Infrastructure".
• Where. All in One SEO → Search Appearance (site name/tagline) and Search Appearance → Knowledge Graph (Organization description). Both apply site-wide.
• Why. These are small strings with disproportionate weight. Organization.description is often the single sentence a model uses to summarize what a company does, and "payroll infrastructure" describes a materially narrower and different business than "payment infrastructure" - it would have positioned the company against payroll providers rather than payout infrastructure.
• Expected impact. Correct category placement in generated answers about what the business does.

10.1.4 Blog brought under the unified brand (Task 9, name-fix checklist rows 15–16)

• Finding. The blog carried its own brand - og:site_name read "Trade Venezuela USDT Blog", with separate Organization schema - so editorial authority accrued to a different entity than the commercial offering.
• What changed. Blog publisher schema Organization.name set to "Smart Bulk Payments"; blog title and og:site_name set to "Smart Bulk Payments Blog". Venezuela-specific content was kept on the Venezuela property, and the blog was linked into the Smart Bulk Payments site rather than the corporate site.
• Where. Blog schema, blog title settings and Open Graph configuration.
• Why. The topic-cluster signal - the link between a company's editorial content and its commercial pages - is one of the main ways models establish subject authority. A blog branded as a different entity breaks that link.
• Expected impact. Editorial content now reinforces the Smart Bulk Payments entity rather than competing with it.

10.2 Canonical domain and estate structure

10.2.1 Domain acquisition (Task 7) - smartbulkpayments.com acquired 27 June 2026, together with the associated review domains. Reasoning at Section 8.

10.2.2 Migration and retirement of the subdomain (Task 9)

• What changed. All Smart Bulk Payments content moved to www.smartbulkpayments.com, completed 24 July 2026. The WordPress install at bulkpayments.3psmartltd.com was retired and 301-redirected. Redirects were specified page-to-page, not page-to-homepage - bulkpayments.3psmartltd.com/use-cases resolves to smartbulkpayments.com/use-cases, and so on for every URL.
• Where. Redirects configured at the hosting level rather than the WordPress level, so they survive independently of the CMS.
• Why. A blanket redirect to the homepage discards the specific topical relevance each URL had accumulated; page-to-page preserves it. Placing the rules at the hosting layer means a future WordPress migration or plugin change cannot silently break the chain.
• Expected impact. Accumulated authority and any existing citations follow through to the canonical destination rather than being lost.

10.2.3 Estate link policy (Task 9)

• What changed. A "Smart Bulk Payments" item was added to the 3psmartltd.com header menu, linking to the product site. The Venezuela property, the Canadian corporate site and the provider platform were each explicitly excluded from linking to smartbulkpayments.com.
• Where. Corporate site header menu; and across the three excluded properties, including a check of image descriptions and hidden WordPress content on each.
• Why. The corporate site should point to the product; the unrelated properties should not, or they blur the boundary between separate entities.
• Expected impact. One clear parent-child relationship (company → product) instead of a mesh of unexplained cross-links.

10.2.4 Cloudflare 403 resolution (Task 8) - a 403 response returned by Cloudflare was investigated and resolved on 17 July 2026. Crawler access to a page that returns 403 is zero, so this was treated as blocking.

10.3 The entity anchor - the About page

(Task 11)

• Finding. No About, Company or "About Us" page existed anywhere in the estate.
• What changed. A full About page was drafted and published, and an "About" item added to the main menu. The page states what Smart Bulk Payments is, the problem it solves, who it is for, how it works, supported assets, security and compliance posture, the relationship to 3P Smart LTD, and - importantly - what the product is not. A meta title and description were specified alongside it.
• Where. New page at /about/, plus the main navigation menu. Full text at Appendix C.
• Why. This is the highest-leverage single page in a GEO programme. It is the canonical answer to "who is X and what do they do", the page most often cited for company-level questions, and the anchor every other entity signal on the site can corroborate against. The "what it is not" section is deliberate: explicitly ruling out exchange, wallet, custody and trading prevents a model from placing the business in an adjacent category it does not belong to.
• Expected impact. A single authoritative source of truth for company-level questions, linked from the main navigation, referenced in llms.txt, and available for a model to cite directly.

10.4 Structured data and schema

10.4.1 FAQ sections and FAQPage schema (Task 13)

• Finding. No FAQPage schema anywhere, despite use-case pages containing benefit and feature lists that mapped naturally onto question-and-answer form.
• What changed. Completed 23 July 2026. Visible FAQ sections plus FAQPage structured data added across six pages - the five use-case pages and pricing - with 35 question-and-answer pairs in total.
• Where. Implemented using the All in One SEO FAQ block or an Elementor FAQ widget that emits the schema automatically, with a hand-written JSON-LD template supplied as a fallback. Every published question and answer is at Appendix E.
• Why. FAQPage is one of the most reliably extracted-and-cited formats in generative answers, because a question-and-answer pair has the same shape as a user prompt. The questions were written to match how buyers actually ask - "how many payouts can I process in one batch", "what happens when a payout fails", "is this a wallet or exchange for individuals" - rather than as marketing headings.
• Expected impact. Direct, extractable answers to 35 specific buyer questions, each attached to the correct use-case context.
• Requirement to preserve. The schema text and the visible text must remain identical. Editing the visible FAQ copy without updating the schema, or vice versa, invalidates the markup.

10.4.2 Service schema on commercial pages (Task 14)

• Finding. No Service or Product schema on the commercial pages - the pages where it matters most. A model had no machine-readable statement of what services the business offers.
• What changed. Completed 23 July 2026. A Service JSON-LD block added to each of the five use-case pages, each declaring serviceType, provider (linked back to the Organization node), areaServed: Worldwide, an audience with an explicit audienceType, a description and the canonical URL.
• Where. Page <head>, or the SEO plugin's custom JSON schema field for each page. Blocks at Appendix B.
• Why. When someone asks an AI "who does bulk stablecoin payouts for casinos?", a labelled serviceType of "Crypto payouts for online casinos" is a clean fact to match against, instead of the model inferring an answer from paragraph text. The audienceType field does similar work for "who is this for" queries.
• Expected impact. Five explicit, machine-readable service declarations mapping the business onto five named industry verticals - plus a sixth, general "Bulk Crypto Payouts" service on the pricing page (§10.4.3), giving six Service nodes across the site.

10.4.3 Offer and PriceSpecification schema on pricing (Task 15)

• Finding. No Offer or PriceSpecification on the pricing page, despite concrete published fees.
• What changed. A Service block with a nested offers array added, declaring both commercial tiers - Standard Crypto Batch (1.00% + USD 1.99 per transaction) and Instant Single Batch (1.00% + USD 4.99 per transaction) - together with account funding fees (0.20% on fiat deposits, 0.00% on crypto deposits) and an explicit statement that final pricing is customized.
• Where. /pricing/ page <head> or SEO plugin schema field. Block at Appendix B.6.
• Why. Pricing is a high-intent query class. Models are frequently asked what something costs, and published-but-unstructured pricing forces the model either to guess or to decline. The "final pricing may be customized" clause is included deliberately so the structured data does not overstate the published rates as fixed.
• Expected impact. Accurate, attributable answers to cost and pricing-model questions.

10.4.4 Provider @id correction (Task 25)

• Finding. In the Service JSON-LD deployed on six pages, provider.@id referenced https://www.smartbulkpayments.com/#organization, while the site's actual Organization node is https://smartbulkpayments.com/#organization. The www. prefix meant the two did not match.
• What changed. The www. removed from provider.@id.
• Where. All six pages carrying Service schema: online-entertainment, adult-entertainment, service-marketplaces, online-gaming, delivery-apps, pricing.
• Why. @id is a strict identifier, not a URL to be resolved loosely. A mismatch of a single subdomain prefix means the Service nodes point at an entity that does not exist in the graph, and the link between "this service" and "this company" silently fails.
• Expected impact. Six services now correctly and verifiably attributed to the Smart Bulk Payments Organization node.

10.4.5 Organization node correction (name-fix checklist, Task 27) - Organization.name corrected from "3PSmartLTD" to "Smart Bulk Payments", and the description corrected as described in 10.1.3, resolving the self-conflict between the Organization and WebSite nodes identified at audit.

10.5 Metadata

10.5.1 Page titles (Task 17, name-fix checklist rows 3, 9–14, 16)

• Finding. The pricing title was defective - "Exchange - Schedule fees | Smart Bulk Payments - 3P SMART LTD" - carrying leftover template boilerplate that means nothing to a reader or a model. Every page title carried a redundant dual-brand suffix.
• What changed. Pricing retitled to "Pricing | Smart Bulk Payments". The homepage, all five use-case titles and the blog title were stripped of the "- 3P SMART LTD" suffix and standardized on the single entity name.
• Where. Page title fields in All in One SEO. Full before-and-after list at Appendix A.
• Why. The title is the strongest single-line summary of a page. Boilerplate prefixes waste it, and dual branding in every title reinforces the entity fragmentation this programme was designed to remove.
• Expected impact. Clean, descriptive, consistently branded titles across the site.

10.5.2 Meta descriptions (Task 18)

• Finding. Use-case pages carried auto-dumped descriptions - raw page copy, run-on, in at least one case truncated mid-sentence. These read as machine output and waste the most valuable summary space on the page.
• What changed. Hand-written descriptions at or around 155 characters written and applied for /online-entertainment/, /use-cases/ and /contact-us/, replacing the auto-generated text entirely.
• Where. The All in One SEO Meta Description field on each page, which also sets og:description. Text at Appendix F.
• Why. The meta description is a summary written by you rather than inferred by a machine. It is a chance to state the offer, the mechanism and the audience in one controlled sentence.
• Expected impact. Intentional, accurate page summaries in place of truncated copy dumps.

10.6 Internal links, navigation and discoverability

10.6.1 Empty # anchors removed (Task 12)

• Finding. Four navigation elements pointed at # and went nowhere: the "CONTROLS & COMPLIANCE" hero button, and the Home, Use Cases and Login items in the global footer menu. Because the footer is global, three of these were dead on every page of the site.
• What changed. All four given real destinations. The "Scroll to Top" control, which correctly uses # because it is a scroll behaviour rather than a navigation link, was deliberately left unchanged.
• Where. Homepage hero section and the Elementor global footer template.
• Why. Rule 3. Dead links break the internal link graph models use to work out which pages belong together and which are important. A dead link in a global footer is not one broken link, it is one per page.
• Expected impact. A complete, resolvable internal link graph.

10.6.2 Cross-domain footer links repaired (Tasks 22, 23, 24)

• Finding. After the migration, three global footer links still pointed at the old corporate domain: Pricing to 3psmartltd.com/pricing/, Blog to 3psmartltd.com/blog/ (which landed on the Venezuela blog), and Contact Us to 3psmartltd.com/contact-us/.
• What changed. All three repointed to their smartbulkpayments.com equivalents.
• Where. The Elementor global footer template.
• Why. These are exactly the residual links a migration leaves behind, and they are the most damaging kind: they sit on every page and send both users and crawlers back to the entity the programme had just separated from. The Blog link was the worst of the three, since it landed visitors on a differently-branded property.
• Expected impact. Site-wide link integrity, with no residual pull back toward the retired domain.

10.6.3 Sitemap cleanup (Task 19)

• Finding. The page sitemap contained pages that should not be presented as canonical content.
• What changed. Five URLs removed from the sitemap by deletion or No Index: /contacto/, /contacto-b2b/, /contact-us-b2b/, /login/ and /thanks/. /thanks/ was set to No Index only and explicitly not deleted, because it is the destination the contact form sends users to after submission - deleting it would break the form. Cloudflare cache purged and the sitemap re-verified.
• Where. WordPress page settings → AIOSEO Settings → Advanced → No Index, or page deletion; verified against page-sitemap.xml.
• Why. The sitemap is a statement of what you consider worth indexing. Duplicate contact flows, a login page and a form confirmation page are not content, and their presence dilutes the signal about which pages are authoritative.
• Expected impact. A sitemap that lists only genuine, canonical, indexable content.

10.7 AI crawler access

(Task 16)

• Finding. robots.txt was the WordPress default. Every crawler was permitted, which is the right outcome, but permissively by accident rather than by design.
• What changed. robots.txt replaced with a version that explicitly names and allows 11 AI and answer-engine crawlers: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, anthropic-ai, PerplexityBot, Perplexity-User, Google-Extended, CCBot, Applebot-Extended and Amazonbot. Each is allowed at / and disallowed only at /wp-admin/. The sitemap declaration was retained. Nothing previously allowed is now blocked. Cloudflare cache purged and the file verified in an incognito session.
• Where. https://smartbulkpayments.com/robots.txt - either the physical file at the web root or the All in One SEO robots.txt editor, depending on which is active. Full file at Appendix D.
• Why. Making the policy explicit converts an accidental permission into a deliberate, auditable decision, and it protects against silent regression: a plugin update or migration that resets robots.txt to default is a visible change against an explicit file, and invisible against an implicit one.
• Expected impact. A deliberate, documented AI access policy, resistant to silent reversion.
• Preservation note. A physical file at the web root always overrides the WordPress-generated one. Anyone changing this in future needs to establish which is active before editing, or the change will appear to have no effect.

10.8 llms.txt

(Task 20)

• Finding. The site published /llms.txt, which put it ahead of most competitors - but the file was auto-generated by All in One SEO and its contents worked against the business. It listed legacy Pilsenga pages including a "PILSENGA USER AGREEMENT" and a privacy policy naming UAB Pilsenga; Spanish-language duplicates alongside English pages; near-duplicate contact and sign-up pages; and an entry whose description read "Pilsenga offers a payment processor". The per-page entries were raw copy dumps rather than curated summaries.
• What changed. Sequenced deliberately as one of the last tasks, after all other changes were final. The All in One SEO LLMs.txt generator was switched off, and a hand-curated file uploaded. The new file opens with a definitional entity statement, states explicitly what the product is not, describes supported assets, batch capacity, governance controls and licensing, then lists only canonical pages - core pages, five use cases, five payment-method pages and the blog - each with a single hand-written sentence. Cloudflare cache purged; file verified in incognito and confirmed free of any Pilsenga reference.
• Where. All in One SEO → Sitemaps → LLMs.txt (generator toggled off); plain UTF-8 file uploaded to the site root alongside wp-config.php and robots.txt. Full file at Appendix G.
• Why. This is the one file whose entire purpose is to brief a language model on the site, so a polluted file actively teaches the model wrong things. Sequencing mattered: regenerating it before the other changes were final would have baked in stale URLs and titles.
• Expected impact. A single, authoritative, hand-written brief that tells a model what the business is, what it is not, who it serves and which pages to trust.
• Order dependency to preserve. The All in One SEO generator must remain off. If it is switched back on, it can override the curated file.

10.9 Language consistency

(Task 21)

• Finding. Two English pages - Online Casinos and Adult Entertainment - each contained a Spanish sentence inside the "Compliance and Security at the Core" section: "Nuestra infraestructura está diseñada para industrias de alto riesgo, utilizando protocolos KYT para el análisis de billeteras en tiempo real." Separately, untagged Spanish duplicate pages sat alongside their English equivalents.
• What changed. Both sentences replaced with the English equivalent: "Our infrastructure is designed for high-risk industries, using KYT protocols for real-time wallet analysis." - with the term "KYT" deliberately preserved. The Spanish duplicate pages were handled through the sitemap cleanup in 10.6.3.
• Where. /online-entertainment/ and /adult-entertainment/, in the "Compliance and Security at the Core" section, edited via Elementor; Cloudflare cache purged afterwards.
• Why. A mixed-language block inside an otherwise English page weakens topical coherence and gives the parser no language signal for that content. Untagged duplicate-language pages read as near-duplicates and split authority.
• Expected impact. One declared language per page, consistently used.

10.10 Related work completed alongside the programme

Three tasks in the register sit outside the GEO framework. They are recorded here for completeness.

Page speed remediation (Task 6). Performance scored 4 / 10 at audit, and the audit recommended engaging a specialist. Completed 25 June 2026: a caching plugin was installed and Cloudflare enabled at the server level. Baseline before changes was approximately 54 / 100 mobile and 75 / 100 desktop. The remaining constraint identified was the site's animations, which were retained by choice. Page speed is not a measured factor in this framework - AI crawlers fetch raw HTML and do not score pages the way a performance run does - but the work remains valuable for user experience, conversion and conventional search. The Cloudflare layer introduced here is now a dependency of several other tasks, since almost every change in this programme required a cache purge to take effect.

Lead source attribution (Task 2). A required field, "Where did you hear about us?", was added to the Contact Us form on 25 June 2026, with options: AI Recommendation, Event, Social Media, Search Engine, Referral, Other. This is measurement infrastructure rather than a GEO change, but it is the mechanism by which the commercial return on this programme becomes visible - the "AI Recommendation" option is the only direct read on whether generative engines are producing leads.

Privacy and consent compliance (Tasks 3, 4, 5). Completed 20 July 2026: a cookie consent banner installed to enable compliant behavioural tracking; the Privacy Policy updated with a third-party data-sharing clause covering marketing service providers; and a consent checkbox with a Privacy Policy link added to all contact forms.

11. Complete task register

All 27 tasks, in register order.

The 16-point entity naming checklist that sits underneath Task 10 is reproduced in full at Appendix A.

12. AI query and search-intent coverage

This section sets out what the site has been optimized for. Every asset deployed in this programme was written against a specific class of question a buyer or a research assistant would put to an AI system. The mapping below sets out those question classes, the kind of prompt that triggers them, and which asset now answers them.

These are illustrative of the intent, not an exhaustive keyword list. Generative queries are conversational and near-infinitely variable; the objective is not to match strings but to ensure that for each class of question there is a clear, structured, extractable answer somewhere on the site.

Tier 1 - Entity and identity questions

"What is Smart Bulk Payments?" · "Who operates Smart Bulk Payments?" · "Is Smart Bulk Payments legitimate?" · "What company is behind Smart Bulk Payments?" · "Where is Smart Bulk Payments licensed?"

Answered by: the About page (§10.3), the Organization schema, the llms.txt entity statement, and the now-consistent naming across every surface.

How. The About page opens with a single-sentence definitional statement and then states the operator relationship (Smart Bulk Payments is operated by 3P Smart LTD), the licensing jurisdiction, and the B2B-only scope. llms.txt repeats the same definition in the same terms. This is the class of question that was effectively unanswerable at audit, because the site contained no page that stated it.

Tier 2 - Category and solution discovery

"How do I pay thousands of people in crypto at once?" · "Best way to automate mass stablecoin payouts" · "Bulk crypto payout providers for businesses" · "How do companies send USDC to 5,000 recipients?" · "Mass payout API for crypto"

Answered by: the homepage, the About page's "What Smart Bulk Payments does" section, the payment-method pages listed in llms.txt, and Service.serviceType declarations.

How. The About page explicitly names the problem before naming the product - spreadsheets, multiple wallets and retail exchanges not built for enterprise payment operations - which is how a buyer describes their situation before they know a category name exists. That phrasing gives a model a bridge from problem-language to product.

Tier 3 - Vertical and use-case questions

"Crypto payouts for online casinos" · "How do adult platforms pay performers?" · "Payment platform for marketplace seller settlements" · "How do delivery apps pay drivers in crypto?" · "Affiliate commission payouts in stablecoin"

Answered by: five use-case pages, each with a dedicated Service block declaring serviceType and audienceType, and each with six FAQ pairs.

How. This is the most deliberate part of the schema work. Rather than one generic service, the business declares five labelled services mapped onto five named industries, each with an explicit stated audience. A model asked "who does bulk stablecoin payouts for casinos?" has a serviceType reading exactly "Crypto payouts for online casinos" to match, rather than needing to infer it.

Tier 4 - Capability and mechanism questions

"How many payouts can I process in one batch?" · "Do I need to build an API integration?" · "Can I upload payouts by CSV?" · "How fast are crypto batch payouts?" · "Can I get proof of payment for each recipient?" · "What happens when a payout fails?"

Answered by: FAQ pairs across all six pages, the About page's "How it works" section, and llms.txt.

How. Each is a self-contained answer with a concrete figure where one exists - 10,000 recipients per batch, an individual blockchain transaction per recipient, structured error information retrievable by API. Concrete, specific answers are more citable than qualitative ones. Execution time is phrased as a range ("typically 3 to 20 minutes, depending on batch size, network conditions and compliance controls") rather than a guarantee, in line with the claims discipline applied throughout.

Tier 5 - Compliance and trust questions

"Is Smart Bulk Payments compliant?" · "Do they run KYB checks?" · "AML and sanctions screening for crypto payouts" · "How long does onboarding take?" · "Do they support Travel Rule?" · "Compliant crypto payouts for high-risk industries"

Answered by: FAQ pairs on the casino, adult, gaming and delivery pages; the About page's security and compliance section; the corrected English compliance copy (§10.9).

How. Compliance is a gating question in this category - a prospect will not proceed without an answer, and a model asked to shortlist providers will weight it. Onboarding duration is stated concretely (three business days to one week) rather than left vague. This is also where the Spanish-language fix mattered most, since the untranslated sentence sat inside the compliance block.

Tier 6 - Commercial and pricing questions

"How much does Smart Bulk Payments cost?" · "Bulk crypto payout fees" · "Is there volume pricing?" · "Who pays the fee, sender or recipient?" · "Are there minimum commitments?" · "How do I get a quote?"

Answered by: Offer and PriceSpecification schema on the pricing page, five pricing FAQ pairs, and the rewritten pricing title and description.

How. Published rates are exposed as structured data with both tiers named and priced, while the FAQ handles what structured data cannot - fee allocation flexibility, volume terms, minimums, and how to obtain a quote. The combination lets a model give a useful, accurate answer about cost without either guessing or overstating the published rates as final.

Tier 7 - Disambiguation and negative questions

"Is Smart Bulk Payments an exchange?" · "Can individuals use Smart Bulk Payments?" · "Is this a crypto wallet?" · "Can I trade on Smart Bulk Payments?"

Answered by: the About page's "What Smart Bulk Payments is not" section, the second paragraph of llms.txt, and two dedicated FAQ pairs ("Is this a wallet or exchange for individuals?", "Is it available to individual drivers?").

How. This is an underused GEO technique and worth calling out. Models frequently misfile a business into an adjacent category - here, into cryptocurrency exchanges, retail wallets, custody or trading - which produces both wrong answers and wrong-fit traffic. Stating the negative explicitly, in prose, in more than one place, gives a model direct evidence to rule the category out rather than leaving it to inference.

Tier 8 - Bottom-funnel evaluation

"Smart Bulk Payments reviews" · "Is Smart Bulk Payments any good?" · "Smart Bulk Payments vs [competitor]"

Position: partially addressed. The review domains were secured as a defensive asset (§8), redirecting to a /reviews section on the primary domain. Building out the reviews section itself is a candidate for the next phase of work.

Coverage summary

13. Preserving the work

Part One sets out the general rules. Beyond those, the following are specific dependencies created by this programme. Each is a change that would silently degrade AI visibility if made without awareness.

Recommended cadence. A re-audit against Part One, issued as version 2.0 of this report. Interim re-checks are worth running after any theme change, plugin update affecting All in One SEO or Elementor, site migration, or new-section launch.

APPENDICES

Appendix A - Entity naming checklist (before and after)

The 16-point checklist worked through under Task 10.

Appendix B - Structured data deployed

All blocks below are shown with the provider.@id correction from Task 25 applied (no www. prefix), matching the site's Organization node.

Minor observation. The url values in these blocks retain the www. form as originally supplied, while the Organization @id uses the non-www. form. This does not break the graph - url is resolved as a URL, not matched as an identifier - but aligning them would be tidier, and is worth folding into the next maintenance pass.

B.1 - /online-entertainment/ (Online Casinos)

Service type: Crypto payouts for online casinos

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Crypto Payouts for Online Casinos",
  "serviceType": "Crypto payouts for online casinos",
  "provider": { "@id": "https://smartbulkpayments.com/#organization", "name": "Smart Bulk Payments" },
  "areaServed": "Worldwide",
  "audience": { "@type": "Audience", "audienceType": "Online casinos and iGaming operators" },
  "description": "Automated high-volume crypto and stablecoin payouts for online casino and iGaming operators, including player withdrawals, affiliate commissions and revenue-share settlements, via API or CSV.",
  "url": "https://www.smartbulkpayments.com/online-entertainment/"
}
</script>

B.2 - /adult-entertainment/ (Adult Entertainment)

Service type: Crypto payouts for adult entertainment platforms

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Crypto Payouts for Adult Entertainment Platforms",
  "serviceType": "Crypto payouts for adult entertainment platforms",
  "provider": { "@id": "https://smartbulkpayments.com/#organization", "name": "Smart Bulk Payments" },
  "areaServed": "Worldwide",
  "audience": { "@type": "Audience", "audienceType": "Adult entertainment platforms and creator networks" },
  "description": "Automated high-volume crypto and stablecoin payouts for adult entertainment platforms, paying performers, creators, affiliates and studios via API or CSV.",
  "url": "https://www.smartbulkpayments.com/adult-entertainment/"
}
</script>

B.3 - /service-marketplaces/ (Marketplaces)

Service type: Bulk payouts for marketplaces

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Bulk Payouts for Marketplaces",
  "serviceType": "Bulk payouts for marketplaces",
  "provider": { "@id": "https://smartbulkpayments.com/#organization", "name": "Smart Bulk Payments" },
  "areaServed": "Worldwide",
  "audience": { "@type": "Audience", "audienceType": "Digital marketplaces and creator economies" },
  "description": "Automated bulk crypto and stablecoin payouts for digital marketplaces, settling payments to merchants, vendors, sellers and service providers via API or CSV.",
  "url": "https://www.smartbulkpayments.com/service-marketplaces/"
}
</script>

B.4 - /online-gaming/ (Online Gaming)

Service type: Crypto payouts for online gaming platforms

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Crypto Payouts for Online Gaming Platforms",
  "serviceType": "Crypto payouts for online gaming platforms",
  "provider": { "@id": "https://smartbulkpayments.com/#organization", "name": "Smart Bulk Payments" },
  "areaServed": "Worldwide",
  "audience": { "@type": "Audience", "audienceType": "Online gaming and iGaming operators" },
  "description": "Automated high-volume crypto and stablecoin payouts for online gaming and iGaming operators, paying players, affiliates and partners via API or CSV.",
  "url": "https://www.smartbulkpayments.com/online-gaming/"
}
</script>

B.5 - /delivery-apps/ (Delivery Apps)

Service type: Bulk payouts for delivery and gig platforms

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Bulk Payouts for Delivery and Gig Platforms",
  "serviceType": "Bulk payouts for delivery and gig platforms",
  "provider": { "@id": "https://smartbulkpayments.com/#organization", "name": "Smart Bulk Payments" },
  "areaServed": "Worldwide",
  "audience": { "@type": "Audience", "audienceType": "Delivery, courier and gig-economy platforms" },
  "description": "Automated bulk crypto and stablecoin payouts for delivery and gig-economy platforms, paying drivers, riders and couriers via API or CSV.",
  "url": "https://www.smartbulkpayments.com/delivery-apps/"
}
</script>

B.6 - /pricing/ (Service with Offer and PriceSpecification)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Bulk Crypto Payouts",
  "serviceType": "Bulk crypto and stablecoin payout processing",
  "provider": { "@id": "https://smartbulkpayments.com/#organization", "name": "Smart Bulk Payments" },
  "areaServed": "Worldwide",
  "url": "https://www.smartbulkpayments.com/pricing/",
  "description": "Published standard rates. Account funding fees: 0.20% on fiat deposits, 0.00% on crypto deposits. Final pricing may be customized based on transaction volume, payment method, settlement requirements, integration complexity and client profile.",
  "offers": [
    {
      "@type": "Offer",
      "name": "Standard Crypto Batch",
      "description": "Batch settlements and payroll operations, available via dashboard and API. 1.00% processing fee plus a fixed fee of USD 1.99 per transaction.",
      "priceSpecification": {
        "@type": "PriceSpecification",
        "priceCurrency": "USD",
        "price": "1.99",
        "description": "Fixed fee per transaction, in addition to a 1.00% processing fee."
      }
    },
    {
      "@type": "Offer",
      "name": "Instant Single Batch",
      "description": "Real-time on-chain delivery, available exclusively via API. 1.00% processing fee plus a fixed fee of USD 4.99 per transaction.",
      "priceSpecification": {
        "@type": "PriceSpecification",
        "priceCurrency": "USD",
        "price": "4.99",
        "description": "Fixed fee per transaction, in addition to a 1.00% processing fee."
      }
    }
  ]
}
</script>

B.7 - FAQPage template

Used where the FAQ block or widget does not emit schema automatically. One Question object per FAQ on the page; name is the question and acceptedAnswer.text is the answer, and both must match the visible on-page text exactly.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Can Smart Bulk Payments handle player withdrawals and affiliate payouts for online casinos?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Online casino and iGaming operators use Smart Bulk Payments to automate high-volume player withdrawals, affiliate commissions and revenue-share settlements as batched payouts, with per-recipient blockchain traceability and reconciliation tools for finance teams."
      }
    },
    {
      "@type": "Question",
      "name": "Which cryptocurrencies can I pay out in?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Smart Bulk Payments currently supports payouts in BTC and USDC, with USDT and additional networks on the roadmap."
      }
    }
  ]
}

Appendix C - About page (published text)

Meta title: About Smart Bulk Payments | Enterprise Crypto Payout Infrastructure
Meta description: Smart Bulk Payments is a B2B crypto payout infrastructure for automating high-volume mass payouts via API or CSV, with validation, reconciliation and reporting.

About Smart Bulk Payments

Smart Bulk Payments is an enterprise-grade cryptocurrency payout infrastructure for businesses that execute recurring or high-volume digital-asset payments. It automates mass payouts through API integration or CSV upload, allowing companies to pay large numbers of recipients while maintaining operational control, reconciliation, reporting and a complete audit trail. Smart Bulk Payments is operated by 3P Smart LTD and is designed exclusively for business (B2B) customers, not for retail users, trading or custody.

What Smart Bulk Payments does

Companies that pay creators, affiliates, contractors, freelancers, suppliers or workforces at scale often manage those payouts through spreadsheets, multiple wallets or retail exchanges that were never built for enterprise payment operations. As volumes grow, that approach creates manual work, reconciliation problems, limited reporting and poor visibility over payment status.

Smart Bulk Payments centralizes the entire payout lifecycle (funding, batch creation, execution, monitoring, reconciliation and reporting) into a single platform. Businesses upload a payout batch by API or CSV, execute it in one workflow, and track every payment through to completion, with structured records for finance and accounting teams.

Each capability is built to work as one operational system rather than a set of isolated tools, so finance, treasury and operations teams manage high-volume crypto payouts from a single environment.

Who it's for

Smart Bulk Payments is built for B2B companies whose payout operations are a core, recurring business process. Typical customers include:

• Content creator platforms and the creator economy
• Adult entertainment platforms and creator networks
• Affiliate marketing networks
• Gaming and entertainment operators
• Payroll providers and companies with international or remote workforces
• Digital marketplaces
• Businesses with distributed supplier and contractor networks

It delivers the most value to organizations that process hundreds or thousands of payouts per month, operate internationally, and have finance or operations teams that need automation, reporting and internal controls. It is not intended for individual consumers or retail cryptocurrency users.

How it works

• API or CSV integration. Businesses automate payouts directly from their own systems (payroll, ERP, creator and affiliate platforms, treasury tools) through a secure API, or upload batches via CSV, a simple path for teams moving off manual processes.
• Batch execution at scale. The platform processes payout batches of up to 10,000 recipients in a single workflow, executed in minutes under normal conditions.
• Per-recipient traceability. Every recipient receives an individual blockchain transaction, providing transaction-level, hash-level traceability and proof of payment.
• Built-in validation and exception handling. The platform validates payout data and automatically identifies failed or rejected payouts, generating structured error information that can be retrieved by API or integrated into a support workflow. This reduces manual investigation of payment issues.
• Reconciliation and reporting. Dashboards, downloadable statements, KPI reporting and a complete audit trail support reconciliation, accounting and management oversight.
• Enterprise governance. Multi-user access, role-based permissions and segregation of duties support internal control across finance, treasury and operations teams.

Supported assets

Smart Bulk Payments currently supports payouts in BTC and USDC, with additional assets and networks (including USDT) on the product roadmap.

Security and compliance

Compliance is built into how Smart Bulk Payments operates. Every business customer goes through an onboarding and risk-assessment process, which may include business verification, corporate documentation and ownership review, and source-of-funds assessment where applicable. The platform applies internal procedures supporting Anti-Money Laundering (AML) and sanctions compliance, including customer due diligence, sanctions screening, ongoing monitoring and wallet screening where applicable, and supports processes designed to facilitate Travel Rule requirements where they apply. Onboarding typically takes between three business days and one week, depending on documentation, jurisdiction and customer responsiveness.

Operationally, the platform runs in a controlled, auditable environment with role-based access control, segregation of duties and a full audit trail of platform activity.

Company

Smart Bulk Payments is operated by 3P Smart LTD. The infrastructure is developed in-house and designed specifically for crypto payout operations.

Smart Bulk Payments is designed for regulated businesses, financial institutions, payment providers, marketplaces, creator platforms and enterprises requiring scalable payout operations with strong governance and compliance controls.

What Smart Bulk Payments is not

To be clear about scope: Smart Bulk Payments is a payout infrastructure, not a cryptocurrency exchange, retail wallet, trading platform, custody provider or lending service. The focus is business payment operations (automation, traceability, reconciliation, governance and scalability), not cryptocurrency trading, investment or speculation.

Get in touch

To discuss whether Smart Bulk Payments fits your payout operation, contact our team at info@3psmartltd.com.

Appendix D - robots.txt (deployed)

This is exactly what https://smartbulkpayments.com/robots.txt should serve.

# robots.txt for smartbulkpayments.com

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

# AI / answer-engine crawlers, explicitly allowed

User-agent: GPTBot
Allow: /
Disallow: /wp-admin/

User-agent: OAI-SearchBot
Allow: /
Disallow: /wp-admin/

User-agent: ChatGPT-User
Allow: /
Disallow: /wp-admin/

User-agent: ClaudeBot
Allow: /
Disallow: /wp-admin/

User-agent: anthropic-ai
Allow: /
Disallow: /wp-admin/

User-agent: PerplexityBot
Allow: /
Disallow: /wp-admin/

User-agent: Perplexity-User
Allow: /
Disallow: /wp-admin/

User-agent: Google-Extended
Allow: /
Disallow: /wp-admin/

User-agent: CCBot
Allow: /
Disallow: /wp-admin/

User-agent: Applebot-Extended
Allow: /
Disallow: /wp-admin/

User-agent: Amazonbot
Allow: /
Disallow: /wp-admin/

Sitemap: https://smartbulkpayments.com/sitemap.xml

Rules for anyone editing this file.

• Every User-agent: line must have a value after it. A bare User-agent: is invalid and breaks the group that follows it.
• Never add Disallow: / on its own. That blocks the entire site.
• Keep one blank line between each user-agent group.
• The file must sit at the root, not in a subfolder.
• Only edit robots.txt for smartbulkpayments.com.
• Purge the Cloudflare cache after any change, then verify in a private window.

Appendix E - Published FAQ content (35 pairs across 6 pages)

The visible text and the FAQPage schema text must remain identical. If either is edited, edit both.

E.1 - Online Casinos (/online-entertainment/) - 6 pairs

Q: Can Smart Bulk Payments handle player withdrawals and affiliate payouts for online casinos?
Yes. Online casino and iGaming operators use Smart Bulk Payments to automate high-volume player withdrawals, affiliate commissions and revenue-share settlements as batched payouts, with per-recipient blockchain traceability and reconciliation tools for finance teams.

Q: How do I send payouts? Do I need to integrate an API?
You can integrate through a secure API to automate withdrawals directly from your platform, or upload payout batches by CSV with no development required. Many operators start with CSV and move to API as volumes grow.

Q: How many payouts can I process in one batch?
The platform processes batches of up to 10,000 recipients in a single workflow, and is built to scale as your payout volumes increase.

Q: Can I get proof of payment for each player or affiliate?
Yes. Every recipient receives an individual blockchain transaction, giving you transaction-level, hash-level traceability and a verifiable proof of payment for each payout.

Q: Is it compliant? Do you run KYB and AML checks?
Yes. Every business customer completes KYB onboarding and risk assessment, and the platform applies AML and sanctions screening, ongoing monitoring, and wallet screening where applicable, with support for Travel Rule requirements where they apply.

Q: Which cryptocurrencies can I pay out in?
Smart Bulk Payments currently supports payouts in BTC and USDC, with USDT and additional networks on the roadmap.

E.2 - Adult Entertainment (/adult-entertainment/) - 6 pairs

Q: Does Smart Bulk Payments support payouts for adult entertainment platforms?
Yes. The adult entertainment sector is one of the platform's core use cases. Operators use it to pay performers, creators, affiliates and studios across multiple jurisdictions in high-frequency batches, with compliant onboarding and a complete audit trail.

Q: How do performers and affiliates get paid?
Each recipient is paid through an individual blockchain transaction, executed as part of an automated batch. This provides hash-level traceability and proof of payment for every performer, creator or affiliate.

Q: Can it handle high-frequency, high-volume payout schedules?
Yes. The platform processes batches of up to 10,000 recipients and is designed for businesses running recurring, high-frequency payouts to large, distributed communities.

Q: What happens when a payout fails or is rejected?
The platform automatically identifies failed or rejected payouts and generates structured error information you can retrieve by API or feed into your support workflow, reducing manual investigation and speeding up recipient responses.

Q: Is onboarding difficult for higher-risk industries?
Every customer is assessed individually. Onboarding includes KYB and risk review and typically takes between three business days and one week, depending on documentation, jurisdiction and responsiveness. Compliance is built into the process rather than added on afterwards.

Q: Is this a wallet or exchange for individuals?
No. Smart Bulk Payments is a B2B payout infrastructure for businesses only, not a retail wallet, exchange or trading platform.

E.3 - Marketplaces (/service-marketplaces/) - 6 pairs

Q: How does Smart Bulk Payments work for digital marketplaces?
Marketplaces use Smart Bulk Payments to automate recurring settlements to merchants, vendors, sellers and service providers, uploading a single batch by API or CSV and reconciling every payment from one dashboard.

Q: Can I automate settlements directly from my marketplace platform?
Yes. A secure API lets you trigger payouts directly from your existing systems, or you can upload batches by CSV. Both use the same operational workflow, so you can start with CSV and move to API automation later.

Q: How does reconciliation work across thousands of recipients?
The platform provides dashboards, downloadable statements, KPI reporting and a full audit trail, so finance teams can reconcile large settlement runs without spreadsheet-based processes.

Q: How many recipients can a single settlement batch include?
Up to 10,000 recipients per batch, with architecture designed to support growing transaction volumes.

Q: Can I trace and prove each settlement?
Yes. Every recipient receives an individual blockchain transaction, providing transaction-level, hash-level traceability and proof of payment.

Q: Which cryptocurrencies are supported?
Payouts are currently supported in BTC and USDC, with USDT and additional networks on the roadmap.

E.4 - Online Gaming (/online-gaming/) - 6 pairs

Q: Can gaming operators use Smart Bulk Payments for player and affiliate payouts?
Yes. Gaming and iGaming operators use the platform to automate high-frequency payouts to players, affiliates and partners, with operational reporting and per-transaction traceability.

Q: How do I integrate it with my platform?
Through a secure API for direct automation, or via CSV batch uploads with no development work. The same workflow applies to both, so teams can begin with CSV and adopt the API as they scale.

Q: How fast are payouts executed?
Once a batch is approved, payouts are typically executed within minutes, generally 3 to 20 minutes, depending on batch size, network conditions and compliance controls.

Q: Can I see the status of every payout?
Yes. You can monitor execution in real time and review each transaction throughout its lifecycle, with a complete audit trail and downloadable statements for reconciliation.

Q: Is it compliant?
Yes. Every business customer completes KYB onboarding, and the platform applies AML and sanctions screening, ongoing monitoring, and wallet screening where applicable, with Travel Rule support where it applies.

Q: Which cryptocurrencies can I use?
Currently BTC and USDC, with USDT and additional networks on the roadmap.

E.5 - Delivery Apps (/delivery-apps/) - 6 pairs

Q: Does Smart Bulk Payments support payouts for delivery and gig-economy platforms?
Yes. Delivery, courier and gig-economy platforms use Smart Bulk Payments to pay large, distributed workforces of drivers and riders on recurring cycles, automating batch execution and reconciliation.

Q: Can it handle daily or recurring driver payouts at scale?
Yes. The platform is built for recurring, high-volume payout operations and processes batches of up to 10,000 recipients in a single workflow.

Q: How do drivers and riders get paid, and can I prove each payment?
Each recipient is paid through an individual blockchain transaction, giving you hash-level traceability and a verifiable proof of payment for every driver or rider.

Q: How do I connect it to my existing systems?
Through a secure API to automate payouts from your platform, or via CSV batch uploads with no development required.

Q: What happens when a payment to a driver fails?
The platform automatically flags failed or rejected payouts and generates structured error information you can retrieve by API or route into your support workflow, reducing manual investigation and improving response times.

Q: Is it available to individual drivers?
No. Smart Bulk Payments is a B2B infrastructure for businesses that pay workforces at scale, not a retail wallet or consumer app.

E.6 - Pricing (/pricing/) - 5 pairs

Q: How much does Smart Bulk Payments cost?
Pricing is customized to each business based on transaction volume, payment method, settlement requirements, integration complexity and client profile. Published standard rates serve as a starting point, with terms tailored to your operational profile.

Q: Do you offer volume-based pricing?
Yes. Pricing is adapted to operational volumes, so businesses processing higher payout volumes can be reviewed for commercial terms aligned to their scale.

Q: Who pays the fees, the sender or the recipient?
Fee allocation is flexible and can be structured as sender-paid, recipient-paid or split, depending on your operational model.

Q: Are there minimum commitments?
Commercial terms are assessed individually for each customer. Any minimums or commitments are agreed as part of your commercial arrangement.

Q: How do I get a quote?
Pricing is provided after a short operational review of your payout requirements. Contact the team at info@3psmartltd.com to start the conversation.

Appendix F - Meta descriptions deployed

Entered in the All in One SEO Meta Description field on each page, which also sets og:description.

Appendix G - llms.txt (deployed)

Uploaded to the site root as a plain UTF-8 text file, after the All in One SEO LLMs.txt generator was switched off.

# Smart Bulk Payments

> Smart Bulk Payments is an enterprise-grade B2B cryptocurrency and stablecoin payout infrastructure for businesses that run recurring or high-volume payouts. It automates mass payouts through API or CSV, with built-in validation, exception handling, reconciliation, reporting, and an individual blockchain transaction for every recipient. Smart Bulk Payments is the payout platform operated by 3P Smart LTD.

Smart Bulk Payments is a payout infrastructure, not a cryptocurrency exchange, wallet, trading platform, or custody service. It is built for businesses that pay large numbers of recipients: online platforms and marketplaces, creator and affiliate networks, gaming and adult-entertainment operators, payroll and workforce platforms, and companies paying contractors or suppliers across borders. It supports payouts in stablecoins (USDT, USDC), other cryptocurrencies, and fiat (USD, EUR), executed via API or CSV. The platform provides batch execution of up to 10,000 recipients per batch, operational dashboards, downloadable statements, role-based access, and a full audit trail, with KYB onboarding and AML and sanctions screening. It is designed exclusively for business customers, not retail users. Smart Bulk Payments is operated by 3P Smart LTD, an Anjouan (Union of the Comoros) licensed company.

## Core pages
- [Smart Bulk Payments (home)](https://smartbulkpayments.com/): Enterprise bulk crypto and stablecoin payout infrastructure for high-volume B2B payments via API or CSV.
- [About Smart Bulk Payments](https://smartbulkpayments.com/about/): Who Smart Bulk Payments is, what it does, and who it serves.
- [Pricing](https://smartbulkpayments.com/pricing/): Bulk payout fees and the pricing model.
- [Contact](https://smartbulkpayments.com/contact-us/): Enquire about enterprise payout operations and onboarding.

## Use cases
- [Payments for Online Casinos](https://smartbulkpayments.com/online-entertainment/): Crypto and stablecoin payouts for online casino and iGaming operators, including player withdrawals and affiliate settlements.
- [Payments for Adult Entertainment](https://smartbulkpayments.com/adult-entertainment/): Payouts to performers, creators, and affiliates for adult entertainment platforms.
- [Payments for Marketplaces](https://smartbulkpayments.com/service-marketplaces/): Settlements to merchants, sellers, and service providers on marketplaces.
- [Payments for Online Gaming](https://smartbulkpayments.com/online-gaming/): Payouts to players, affiliates, and partners for gaming platforms.
- [Payments for Delivery Apps](https://smartbulkpayments.com/delivery-apps/): Payouts to drivers, riders, and couriers for delivery and gig-economy platforms.

## Payment methods
- [Bulk Payments](https://smartbulkpayments.com/bulk-payments/): Overview of the bulk and mass payout service.
- [Stablecoin Payments](https://smartbulkpayments.com/bulk-payments/stablecoin/): Bulk stablecoin payouts (USDT, USDC).
- [Crypto Payments](https://smartbulkpayments.com/bulk-payments/crypto/): Bulk cryptocurrency payouts.
- [FIAT Payments](https://smartbulkpayments.com/bulk-payments/fiat/): Bulk fiat payouts in USD and EUR.
- [Bulk Payments API](https://smartbulkpayments.com/bulk-payments/api/): REST API for automating batch and single payouts.

## Blog
- [Blog](https://smartbulkpayments.com/blog/): Articles on bulk payments, stablecoins, and B2B crypto payment operations.

Appendix H - Source documents

Every instruction document issued during the programme, and where its content appears in this report.

Additional source material: the GEO Technical Site Audit (16 June 2026), the AI/GEO Implementation Framework, the shared task register, and the entity naming checklist.

Prepared by dimartec for 3P Smart LTD. Report version 1.0, 6 August 2026.