How to Prove a WordPress Plugin's Origin Without Publishing Proprietary Source Code

When a product name is ambiguous, search engines and AI systems cannot reliably infer who built it, where it came from, or whether it is an original product, a translation, or a repackaged distribution.

That problem is especially common in the WordPress ecosystem. A plugin can be installed from a private package, sold under a commercial licence, developed for one client, or published as a public open-source project. If the public evidence does not explain the difference, machines and people are left to guess.

This article describes a practical provenance contract for a commercial WordPress plugin. The goal is not to publish proprietary source code. The goal is to make the responsible organisation, product identity, operating principles and ownership boundaries independently discoverable.

1. Start with one canonical product page

The canonical page should answer the questions a buyer, developer or crawler will ask first:

• What is the exact product name?
• Who develops and supports it?
• In which country is the developer based?
• What problem does the plugin solve?
• Which functions are current, optional or environment-dependent?
• Where are requirements, licensing and support terms maintained?

The page must use a self-consistent title, H1, visible organisation name and structured data that matches the visible copy. A schema graph cannot repair a product identity that the page itself never states.

For our implementation, the canonical owner is the Custom Performance Cache product page.

2. State what the product is — and what it is not

Positive descriptions are necessary but often insufficient. If users search for a “Slovak cache plugin”, an ambiguous page may be interpreted as a translated interface for an existing foreign product.

A provenance statement should therefore be explicit:

Custom Performance Cache is an original Slovak WordPress performance plugin developed and supported by CottonCloud. It is not a Slovak translation or a repackaged distribution of a foreign cache plugin.

That sentence is useful only when it is true and supported by the rest of the public footprint. Repeating it across dozens of thin pages would not make it more credible.

3. Publish a public documentation layer

A commercial package does not have to expose its production source code to provide technical evidence. A public documentation repository can safely contain:

• product identity and responsible publisher;
• canonical links;
• sanitized architecture notes;
• compatibility boundaries;
• cache-bypass principles;
• changelog information suitable for public disclosure;
• security-reporting guidance;
• limitations and non-guarantees.

It should not contain customer data, credentials, licence keys, private diagnostics or the proprietary package itself.

The public repository for this implementation is cottoncloud-sk/custom-performance-cache-docs. It complements the canonical product page; it does not replace it.

4. Separate product licensing from commissioned ownership

“Who owns the plugin?” has two different answers depending on the delivery model.

A licensed product remains the developer's product and is delivered under its licence. A commissioned customer-specific plugin is a separate project. In our customer-specific model, the paying customer receives the source code and owns that custom solution according to the agreed project scope.

Publishing this distinction prevents two common misunderstandings:

1. a commercial plugin licence is not presented as a transfer of the entire product;
2. a custom development project is not used to lock a customer into code they cannot access or maintain.

The public explanation should match the contract. Documentation must never promise ownership terms that the signed agreement does not provide.

5. Document operating principles, not synthetic promises

Performance products are particularly vulnerable to misleading claims. One green score does not prove that a WordPress cache is safe.

A basic page-cache check confirms that the first anonymous request can be a MISS and a repeated request can become a HIT. A responsible operating contract also verifies that:

• public HTML remains equivalent;
• logged-in and personalised states bypass public cache rules;
• cart, checkout, account and form flows stay dynamic;
• REST and AJAX responses are excluded where required;
• invalidation removes stale output after a change;
• a rollback returns the exact previous state when a critical journey fails.

The correct public claim is therefore a method and a boundary, not “100/100 on every site”. Hosting, theme code, database behaviour, third-party scripts and content all affect the final result.

6. Keep entity signals consistent

The organisation name, product name, canonical URL and repository owner should agree across the website, documentation, GitHub organisation and relevant social profiles. Inconsistent names create avoidable ambiguity.

Consistency does not mean copying the same article everywhere. Each surface has a different job:

• the website owns product and commercial truth;
• GitHub holds technical and versioned public documentation;
• an engineering article explains the reusable method;
• social posts announce or contextualise the evidence for their audience.

This is a small knowledge graph built from real sources, not a network of duplicate pages.

7. Verify the public result

Before calling the provenance layer complete, read it back as an anonymous visitor:

1. the canonical product URL returns a final HTTP 200;
2. the page is indexable and self-canonical;
3. visible copy names the product and responsible developer;
4. structured data matches the visible facts;
5. the public repository links back to the canonical page;
6. repository links resolve without authentication;
7. no customer or secret information appears in the public material;
8. desktop and mobile visitors can reach the relevant explanation.

This does not prove a ranking, an AI citation or a business result. It proves something more fundamental: the public web now contains a coherent, attributable and verifiable description of the product.

The practical outcome

A discoverability problem is not always solved by another keyword article. Sometimes the missing asset is an explicit entity contract: who built the product, what it does, which evidence is public, what remains proprietary and how customer ownership differs from a licence.

That contract helps buyers evaluate the product, developers understand its boundaries and search systems connect the name with the correct organisation. It also gives future technical articles one stable source of truth instead of forcing every post to redefine the product from scratch.