CodeCanyon Nilam - WordPress Plugin

How to Set Up CodeCanyon Nilam to Sell Domains on WordPress

CodeCanyon Nilam is the premium version of ThemeAtelier's Domain For Sale plugin, built to turn a WordPress site into a managed storefront for selling domain names. This guide does not repeat the product card. Instead, it walks through how to prepare your site, where to use the domain sales template, how to configure the offer form, how to test the result, and how to avoid losing inquiries because of small issues with your theme, cache, email delivery, or form protection.

This guide is written for domain portfolio owners, webmasters, agencies, and WordPress administrators who already have the plugin archive and want to test it safely on a live site. We will focus on confirmed features: landing page templates, display options through theme replacement or shortcode, buyer offers, contact details, Google reCAPTCHA protection, SEO settings, colors, typography, background, container width, compatibility with the block editor, Elementor, and third-party forms.

The main idea behind CodeCanyon Nilam is simple: instead of showing a blank parked-domain page, you present a clear sales page with pricing, selling points, contact information, and a form. But the outcome depends on more than just activating the plugin. You need to choose the right display mode, prepare the copy, verify email delivery, avoid breaking your current theme styles, enable spam protection, and understand where the plugin's job ends and the actual domain transfer process begins.

That is why this guide follows a practical workflow. First, we will define who Nilam is a good fit for, then go through installation and initial checks, review the key settings, build a sample page for a single domain, look at portfolio display through a list or grid, and separately cover forms, email, SEO, security, troubleshooting, and comparable alternatives.

What Problem the Plugin Solves for a Domain Owner

Nilam is useful when the owner has a domain that is not being used as a full website but can still attract direct traffic, search visits, branded queries, or buyer interest. A standard registrar parking page offers almost no control: the owner cannot manage the copy, does not get a structured inquiry, cannot tailor the page to the domain's niche, and often depends on a third-party platform. WordPress with Nilam offers a different approach: the domain can be presented like a product without the heavy infrastructure of a full ecommerce setup.

The confirmed product logic includes landing pages for domains, built-in offer and inquiry forms, inquiry management in the admin panel, templates, color schemes, typography, background settings, contact details, SEO options, and display methods through a shortcode, block, or Elementor widget. This is more than a basic contact form. The plugin covers the chain of domain page - buyer offer - inquiry record - owner notification.

When Nilam Makes the Most Sense

The best use case is a small or mid-sized domain portfolio that the owner wants to sell directly. For example, an agency may still own domains from older projects, an investor may hold several brandable names across different niches, or a webmaster may own a domain with clear commercial appeal. In these cases, it helps to create a page quickly where a buyer can see the name, a short description, the price or starting offer, the form, and the contact details.

A second strong use case is showcasing multiple domains on one site. The official materials show both grid and list layouts, along with dedicated domain pages. This works well when a visitor is not looking for one specific name but wants to browse a group of related options. In that setup, Nilam presents the portfolio far more cleanly than a basic list of links inside a WordPress post.

A third use case is selling a domain without relying on a public marketplace as the main point of contact. The owner decides what copy to show, which contact fields to collect, and which emails to send. That said, it is important to remember that the plugin helps you receive and process inquiries, but it does not replace legal review, negotiation, or a secure domain transfer process.

Where the Product May Be Unnecessary

Nilam is not needed if your domains are already being sold entirely through a major external marketplace and your WordPress site is not involved in the conversation. It may also be excessive if the goal is not to sell a domain but to route different domains to different sections of the same site. For that kind of job, domain mapping plugins are a better fit, because the important pieces are DNS, alias domains, SSL, and content mapping, not a purchase form.

Another case is a large-scale domain marketplace with seller accounts, commission logic, public profiles, and complex moderation. Nilam is best understood as a site owner's tool for their own domains, not as a ready-made multi-vendor trading platform with buyer and seller roles.

What to Check Before Installing It on a Live Site

Before installing a domain sales plugin, it is worth doing a quick technical review. It takes less time than troubleshooting later if the form stops sending email, the background does not display correctly, or the sales page gets cached in the wrong state. This check is especially important if the domain already receives traffic or is used in ad campaigns and email outreach.

WordPress, PHP, and Theme Compatibility

The CodeCanyon page lists Nilam as compatible with WordPress, the block editor, Elementor, Contact Form 7, Gravity Forms, WPForms, WPML, and other popular tools. The WordPress.org version of Domain For Sale lists minimum WordPress and PHP requirements, and the changelog confirms ongoing compatibility fixes. It is not wise to turn that into a promise of full compatibility with every possible stack: in real projects, the theme, cache, minification, and third-party forms can affect both the final design and form submission.

Before installation, check the following:

• Whether you are running a current version of WordPress and a supported version of PHP.
• Whether you have a backup of the site and database before enabling a new plugin.
• Whether outgoing email is disabled at the hosting level.
• Whether a caching plugin might still serve an older version of the page.
• Whether you need integrations with third-party forms, the block editor, or Elementor.

A Dedicated Site or a Page Inside an Existing Project

An important decision before configuration is where the sales page will live. If the domain is being sold outright, it usually makes sense to replace the current front-end view with a sales landing page. If the domain still points to an active site, it is better to use a shortcode, block, or internal WordPress page so you do not override the whole project. Nilam's product description highlights this flexibility: the template can be used as a theme replacement or embedded through a shortcode.

Do not enable a mode that changes the entire site appearance until you have tested it on a staging page. For a live project, the safer workflow is to create a draft page first, insert the shortcode or block, open the preview, test the form, styles, and mobile layout, and only then connect the page to navigation or paid traffic.

Email and Spam Protection

Nilam handles buyer offers, which means email deliverability becomes part of setup. If WordPress is not sending email or messages land in spam, the owner may assume the plugin "isn't receiving inquiries" even though the record may still be saved in the admin panel. It is better to configure an SMTP plugin in advance or test the mail channel with a sample form. Google reCAPTCHA also requires prepared keys and the correct domain in the service settings.

Quick pre-launch test: create a test page, submit an inquiry from an external email address, confirm that the offer is saved in the admin panel, that the administrator receives the notification, and that the visitor sees a clear post-submit message.

Installation and First Launch Without Unnecessary Risk

Installing a premium WordPress plugin usually follows the path Plugins - Add New - Upload Plugin. For the free version, WordPress.org describes automatic installation through the directory search and manual ZIP upload. For CodeCanyon Nilam, the flow is similar: upload the ZIP archive, install it, activate it, and then go to the plugin's newly created or available control screens. It is important not to confuse the product package with the plugin archive if the download includes documentation and extra files.

A Safe Activation Sequence

1. Create a full site backup, or at least back up the database and the wp-content folder.
2. Install the plugin by uploading the ZIP archive through the WordPress admin panel.
3. Activate the plugin and check which new menu items appear in the admin area.
4. Create a test domain template or open the demo example if your package includes one.
5. Do not assign the template to the homepage or replace the theme until the form, styles, SEO, and mobile layout have been tested.
6. After the initial check, clear the page cache and open the result as a guest user.

If WordPress shows a PHP warning after activation, do not rush to edit plugin files. The changelogs for Nilam and the free version show that the developer has already fixed PHP warnings and compatibility issues through updates. The correct order is to verify that you are on the latest version, disable conflicting optimizers on the test page, review the hosting error log, and contact support with the exact warning text.

Initial Check After Activation

Right after activation, do not only verify that a menu item exists. Open the public side of the site, confirm that the current theme did not change unexpectedly, and make sure the admin panel still loads without critical errors. Then create a minimal domain page with a temporary title, a short description, a contact email, and a test price or offer mode. That helps you confirm the basic workflow before you start fine-tuning colors, typography, and SEO.

Also check whether the plugin created pages automatically. Nilam's description notes that the system can generate pages that you can add to a menu or place where needed. If such a page appears, do not delete it right away. First, review how it connects to the settings, then decide whether to use it, rename it, or replace it with your own page.

Configuring the Domain Sales Template

The most important area in Nilam is the domain template. This is what determines what a potential buyer sees: the domain name, selling points, the price or starting offer, contact details, the form, background, colors, typography, and related domains. In newer versions, the developer moved some settings into template metaboxes and added a separate custom post type for DFS Template. In practice, that means the template should be treated as its own entity, not just as one global sitewide setting.

What to Fill In First

Do not start with colors. Begin with the content fields, because they are what affect conversion and lead quality. A domain sales page usually needs the following:

• The exact domain name with no typos or extra characters.
• A short explanation of the niche or brand the domain fits.
• A fixed price, starting bid, or a "make an offer" mode, depending on your sales model.
• Contact details or a form through which the buyer can submit an offer.
• A clear call-to-action button that does not imply instant domain transfer if the deal still requires review.
• Additional domains, if you want to show a portfolio or alternatives.

The official demos feature domains with descriptions, a contact block, Make an Offer and Purchase Now buttons, and cards for related domains. You do not need to copy those elements word for word. It is better to tailor the copy to the actual domain: why the name is short, memorable, niche-specific, suitable for a local market, startup, blog, service, or brand.

Choosing a Mode: Dedicated Landing Page or Embedded Display

Nilam supports flexible template usage: you can replace the current theme with a sales template or use a shortcode. The changelog also mentions a Gutenberg block and an Elementor widget for template output. The practical choice depends on what exactly is being sold.

After choosing the mode, save the template and open the page in a separate window while logged out. This matters because administrators often see a different version due to the WordPress admin bar, disabled cache, or permission differences.

Colors, Background, Container Width, and Typography

The official Nilam page confirms two template variations, ready-made color schemes, unlimited color controls, background images, overlay, container width, column spacing, and advanced typography settings. These options help align the domain page with your brand, but they can also hurt readability if you overdo them.

For a typical site, start with a restrained setup:

• Use one main accent color for the offer button and links.
• Check text contrast against the background, especially if you use a photo or a dark overlay.
• Do not make the container too wide: both the form and the value proposition should be easy to read without extra-long lines.
• Keep the form font size large enough for mobile visitors.
• Check column spacing on a tablet layout, not just on a wide desktop monitor.

The best CodeCanyon Nilam settings are not the flashiest ones, but the ones that make the domain easy to understand and the offer easy to submit. If customization pushes the form below the fold, hides the button, or makes the text blend into the background, roll back to one of the built-in schemes and change one setting at a time.

How to Safely Roll Back Questionable Visual Changes

Nilam advertises a settings backup feature. If it is available in your version, use it before making major design changes. If not, record the values manually: take a screenshot of the settings or save a list of your colors, background, and container width. This is especially helpful when multiple people edit the page: marketing changes the copy, design changes the colors, and then the administrator is left figuring out why the form became unreadable.

The Offer Form, Email Notifications, and Spam Protection

On a domain sales page, the form matters just as much as the visual design. A buyer may visit only once, submit an offer, and never return. That means your form setup has to answer three questions: what data you collect, where it goes, and how you protect the form from junk submissions. According to the official sources, Nilam supports a built-in contact form, Google reCAPTCHA, AJAX submission, email notification variables, and third-party form shortcodes.

Which Fields the Inquiry Should Include

The demo pages and WordPress.org descriptions show standard fields such as name, email, phone, offer amount, and message. For a real domain sale, that is usually enough at the first stage. There is no need to turn the form into a long questionnaire: the more fields you require, the fewer submissions you will get. It is better to collect a contact and an offer amount, then clarify the details in follow-up communication.

A minimal field set looks like this:

• The buyer's name or company name.
• An email address for follow-up.
• The proposed amount or a message expressing interest.
• An open comment field if the buyer wants to describe the project.

A phone field makes sense only if you are actually prepared to respond by phone. If not, it can add unnecessary friction. For international buyers, avoid requiring a local phone format.

Built-In Form or Third-Party Shortcode

Nilam supports third-party form shortcodes. That is useful if the site already runs Contact Form 7, Gravity Forms, WPForms, or another tool with CRM integration, anti-spam controls, and familiar email logic. But a third-party form may not know which domain page it belongs to unless you pass that context through a hidden field or a clear text label near the form.

For a single domain, the built-in form is the easiest place to start. For an agency where inquiries need to land in a CRM, an existing form may be more practical, but you should verify that the domain name is included in the email subject or in the message body. Without that, multiple domain pages will send identical emails, and the manager will have no idea which name the inquiry is about.

Email Notifications and Variables

The official CodeCanyon page mentions variables for email notifications, and the WordPress.org changelog mentions fixes for email subject variables as well as the addition of IP address data. That is useful, but it requires restraint. Do not place unverified fields into the email, and do not treat an IP address as proof of identity. IP and device data can help you filter junk or estimate geography, but the deal itself still needs to be verified through normal business steps.

Practical test: send a sample inquiry where the amount, domain, and message are clearly different from any default values. If the email arrives without the domain name or the amount, adjust the notification subject and body before publishing the page.

Google reCAPTCHA and Validation

Nilam advertises support for Google reCAPTCHA, and the changelog notes the addition of form validation. Turn the protection on if the form receives public traffic. At the same time, do not treat reCAPTCHA as a complete solution. It reduces spam volume, but it does not solve deal quality, fake email addresses, or suspicious offers. After enabling it, test submission in a normal browser, in incognito mode, and on a mobile device.

If the form stops submitting after you enable protection, first check the reCAPTCHA keys, the domain in your Google settings, JavaScript caching, and any browser console errors. Do not disable protection permanently because of the first error. A better approach is to temporarily turn off script minification on the form page, test again, and only then look for the actual conflict.

Domain Portfolio Display: Grid, List, and Related Offers

Nilam is interesting not only as a single-domain page. The official materials show a grid, a list, domains with a Details button, "More Domains" cards, filtering, sorting, output limits, column settings, spacing, borders, shadows, pagination, and a shortcode for flexible placement. That changes the use case: the owner can present a portfolio as a compact catalog, with each domain getting its own card and inquiry path.

When to Use a Grid

A grid works best when the domains are roughly equal in weight and the visitor needs to scan options quickly. For example, you might have a group of names for tech blogs, ecommerce stores, education projects, or local services. A grid works well on a "Domains for Sale" page because it saves space visually and lets visitors compare names side by side.

But a grid is a poor fit if each domain needs a longer explanation. In that case, the cards become overloaded, the buttons get pushed down, and the user has to open every page to understand the details. A better solution is to keep the grid descriptions short and move the deeper explanation to each domain page.

When to Use a List

A list works better for domains where the description matters. The official Domain List demo shows domain names, text, and a details button. That format is a better match for portfolios where each name carries its own logic: niche, audience, potential use case, language nuance, or brand angle.

A list is also easier to read on mobile when the cards contain more text. Even so, do not turn the page into an endless feed. Use pagination or a domain limit if the portfolio is large. For both SEO and performance, there is little value in loading dozens of heavy cards on one page unless you truly need to.

Related Domains on a Single Domain Page

The "More Domains" block is useful when a buyer is not sold on the exact domain but is clearly interested in the niche. For example, someone viewing a domain for a fitness project may also be interested in a similar name for a wellness blog. There is no need to display the entire portfolio here. It is better to show 3 to 6 related options based on topic, length, language, or price.

If your version includes filtering and sorting for listings, use those tools as an editorial system rather than decorative features. Group domains by niche first, then decide which groups belong on separate pages. That makes the portfolio clearer for visitors and easier for search engines to understand.

How to Manage Buyer Offers After Publishing

A domain sales page does not end with the click of a button. The owner needs to understand how incoming offers will be handled: which ones look viable, which ones need follow-up, which ones should be declined, and how to avoid losing the conversation history. The official Domain For Sale site describes an offer management dashboard, sorting, CSV export, and expanded inquiry data. That means Nilam can work not only as a polished front-end form, but also as a lightweight lead log.

Even if you only have one domain, keep your offers organized. A buyer may come back a few days later, change the amount, or write from another email address. If the entire history lives only in email, it is easy to lose context: what the first offer was, which domain interested the buyer, and which contact channel they provided. The admin inquiry list gives you a basic layer of structure without requiring a separate CRM.

How to Evaluate an Incoming Offer

There is no reason to respond to every submission in the same way. First, check whether the offer looks like real interest. The amount matters, but so does the quality of the data: name, email, message, domain, submission time, repeated attempts, geography, and device data, if your version includes it. None of that proves the buyer can complete the deal, but it does help you decide whether the lead is worth a long exchange.

A practical triage system might look like this:

• High priority: clear email, specific amount, sensible message, and a use case that matches the domain niche.
• Medium priority: there is contact information and visible interest, but the amount or intent is unclear.
• Low priority: blank message, suspicious address, or identical submissions sent across multiple domains.
• Needs review: the offer looks attractive, but the sender asks you to click an external link or send technical details before any negotiation.

If CSV export is available in your version, use it for periodic exports. That is especially helpful when the portfolio is large or multiple people handle the offers. Just do not store the export in a public website folder: inquiries contain contact data and should be handled as personal information.

How to Reply Without Confusing the Buyer

Your reply should be short and specific. Confirm that the offer was received, mention the domain, explain the next step, and do not promise a transfer before the terms are agreed. If Nilam is set up with confirmation email templates, check the tone carefully: an automated response should not read like final acceptance of an offer if you have not yet reviewed the buyer or the transaction terms.

For multiple domains, it helps to include the domain name in the email subject line. For example, instead of a generic New Offer, use a subject that includes the domain and amount, if your version's notification variables support it. That gives the administrator instant context and makes it easy to see whether the inquiry needs attention or belongs to an old page or a test.

When to Bring in an External Transaction Process

Nilam can capture interest, present the sales page, and send the inquiry data to the owner. After that, the deal stage begins. If the amount is significant, it is better to use a secure external process for payment and transfer rather than trying to finalize everything in a random email thread. The official site mentions Escrow.com integration for Pro scenarios, but availability and configuration need to be verified in your version and in the developer documentation.

The practical rule is simple: Nilam covers the storefront and the initial contact, while escrow, transfer terms, domain handoff, and ownership confirmation require separate attention. Do not blur those stages in the page copy. The buyer should understand that the form submits an offer, not an instant domain transfer.

SEO, Indexing, and Trust Signals on the Domain Page

Nilam advertises SEO settings for domain pages. It is important to interpret that realistically. The plugin can help you fill in metadata and make the page clear and manageable, but it does not guarantee search rankings. Domain landing pages often have limited content, so performance depends on the quality of the description, the history of the domain, its link profile, the technical health of the site, and how well the page matches search intent.

What to Write So the Page Does Not Feel Empty

A buyer needs to understand the value of the domain quickly. Instead of a generic phrase like "domain is for sale," add 4 to 6 specific points: niche, possible project type, memorability, length, readability, geography, language, and the absence of awkward characters. Do not promise profits or invent a story about the domain if it is not verified. A more credible approach is to explain honestly why the name could fit a certain type of business.

A strong page structure looks like this:

• A heading with the domain name and a clear for-sale statement.
• A short paragraph explaining the domain's intended use.
• 2 to 4 advantages of the name without inflated claims.
• A price or an invitation to make an offer.
• The form, contact details, and a short explanation of the next step.
• Related domains, if they are genuinely relevant.

Metadata and Canonical Pages

If Nilam allows you to fill in SEO fields, use them to build a solid snippet: the domain name, the type of offer, and a short description. Do not stuff the meta description with keyword lists. For a single domain, one natural sentence is enough: what is for sale, what niche it suits, and how to submit an offer.

If the site already uses an SEO plugin, make sure the metadata does not conflict. In some cases, the SEO plugin pulls the title from the post, while Nilam outputs its own template. After publishing, inspect the page source or the SEO plugin preview tool and confirm that the title, description, and canonical all match the intended page.

Indexing Pages with Prices and Forms

For publicly listed domains, indexing is usually helpful, but not always. If the domain is being sold privately, it may be better to block indexing through your SEO plugin or not publish the page in navigation at all. If the portfolio is public, make the pages crawlable, add internal links, and do not block important template assets.

The result check is straightforward: open the page as a guest, confirm that the browser title reflects the domain, the form works, and the meta description is not still using a generic default. Then make sure the page is not being served from cache with outdated pricing or old copy.

What to Check in the Search Snippet After Publishing

After publishing, do not stop at a visual page review. On a domain landing page, the main search asset is often the snippet itself. If the title still shows a technical string and the description pulls in the first line of the form, the page will look weaker to a potential buyer. Check the title, description, canonical, and the visible domain name. If you use a separate SEO plugin, confirm that it is not silently overriding Nilam's fields with an unexpected template.

For domain portfolios, avoid duplicate copy. If several pages all use the same text like The domain name is available for sale by its owner, both search engines and humans get a weak signal. Add a unique description to each domain: niche, possible use, language, length, memorability, and geography. That does not require invented promises. It is enough to explain what makes that specific name different from the next one.

Building Trust Without Overmarketing

Domain buyers are often cautious: they want to know who receives the inquiry, what happens after submission, and whether their information disappears into a black hole. That is why the best content near the form is not hype, but calm explanation. State that the owner will review the offer, reply by email, and discuss a secure transfer method. If you use a third-party escrow service, mention it only if the process is actually in place.

Do not overload the page with badges, countdown timers, or urgency messaging if they do not reflect the real process. With a domain page, clarity matters more: the name, its meaning, the price or range, the form, the contact information, and the next step. Nilam provides plenty of visual controls, but trust comes from strong editing and a transparent inquiry flow.

Practical Example: A Sales Page for One Domain

Let us walk through a realistic scenario. The owner has a domain for an education-related project and wants to create a page where visitors can see the name, a short explanation, a starting offer amount, a form, and a couple of related domains. The goal is not to "install the plugin nicely," but to build a working flow where the inquiry is saved and delivered to the administrator.

Goal and Preparation

Goal: create a domain sales landing page with an offer form, test it safely, and only then send traffic to it. Before you begin, WordPress should already be installed, Nilam activated, basic email delivery configured, reCAPTCHA keys prepared if needed, and the display mode chosen: a standalone page or a shortcode.

Setup Steps

1. Create a new domain template or a new entry in the plugin section that manages domains and DFS templates.
2. Enter the domain name, a short description, and a starting offer amount if that is part of your sales model.
3. Select one of the available template variations and a color scheme without changing every design setting yet.
4. Fill in the contact details and configure the form: name, email, offer amount, and message.
5. Enable reCAPTCHA if the page will be public, and verify the keys for the site domain.
6. Set the email subject line so the domain name and offer amount are clearly visible.
7. Add the page as a WordPress draft through a block, Elementor widget, or shortcode if you are not using theme replacement.
8. Open the preview, test the mobile layout, submit a sample inquiry, and check the record in the admin panel.

Expected Result

On the public page, visitors should see the domain, a short description, a clear invitation to submit an offer, the form, and contact information. After submission, the visitor should get a clear confirmation message, and the administrator should receive an email with the inquiry data. In the admin panel, the offer should appear in the list so you can review the contact details, amount, and message.

The Detail That Often Breaks the Test

The most common mistake in this scenario is checking only the design and forgetting about email. The page may look perfect, but the inquiries never reach the administrator because of mail configuration, SPF/DMARC, SMTP, or spam filtering. That is why the final test should verify two outcomes: the offer is saved in WordPress and the email is received. If the email does not arrive but the record is saved, the issue is most likely mail delivery, not the template itself.

Integration with the Block Editor, Elementor, and Third-Party Forms

The Nilam changelog mentions Gutenberg block support, an Elementor widget, and an admin preview for shortcode display. That is an important improvement over older setups where users relied only on manual shortcode placement. You can now build the sales page inside a familiar editor, but builder integration still requires discipline: not every attractive layout works well with the form, plugin styles, and page cache.

WordPress Block and Shortcode

A block is useful for editors who do not want to copy a short code or remember attributes. If the block is available in your version, use it on pages where the surrounding content also needs to be edited in WordPress. The shortcode remains the universal option: you can place it in a post, page, widget, builder template, or another location where WordPress processes shortcodes.

After inserting the shortcode, make sure it is not showing up as plain text. If visitors see a string like [...], the shortcode is not being processed in that location. The fix depends on the theme or builder: use the standard shortcode block, an HTML block that supports shortcodes, or the plugin's widget if one is available.

Elementor and Other Builders

The Elementor widget is useful when the domain page is only one part of a broader landing page. For example, you might keep a branded hero section at the top, then display the Nilam template or offer form, and place FAQ content and related domains below. But do not wrap the template inside very narrow columns, because Nilam already has its own controls for container width, columns, and spacing.

Test the page at three widths: desktop, tablet, and mobile. If the form shifts out of place, first simplify the builder layout, then review the Nilam container settings, and only after that start looking for CSS conflicts. There is usually no need to add custom JavaScript right away: in many cases, the issue is solved by using the correct section width and removing unnecessary inner padding.

A Third-Party Form Inside the Template

Third-party form shortcodes make sense when the site already has a lead-handling workflow in place. For example, the inquiry may need to go to a CRM, email automation, a ticketing system, or a dedicated inbox. In that setup, Nilam handles the domain presentation while the form handles the business process. The key is context. The email subject or a hidden field should make it obvious which page and which domain the inquiry came from.

If you cannot confirm that the third-party form passes the domain name through the workflow, start with Nilam's built-in form first and only then move the process into the CRM. That way, you separate plugin validation from external integration testing.

Final Check Before Sending Traffic to the Page

Before launching ads, email campaigns, or a domain redirect to the new page, run one more review. This is not a formality. It protects you from quiet failures: the form may work only for administrators, the meta description may be blank, reCAPTCHA may fail on mobile, or the cache may still show the old price. On a domain sales page, those issues are especially costly because every visitor could be a potential buyer.

Checklist for a Single Domain

1. Open the page as a guest and make sure the domain, description, and price or offer prompt are visible without scrolling, or with very little scrolling.
2. Check the mobile version: the form should not be too narrow, the button should remain visible, and the background should not cover the text.
3. Submit an inquiry from an external email address using non-generic wording so it is easy to distinguish the test from a default example.
4. Confirm that the inquiry appears in the admin panel and that the email reaches the correct address.
5. Make sure the email includes the domain, the amount or offer, and the buyer's name and email address.
6. Clear the cache and reload the page to verify that the newest version is the one being served.
7. Check the page title, meta description, and canonical if the site uses an SEO plugin.

Checklist for a Portfolio

For a portfolio, add a few extra checks. Open the domain grid or list, test the detail links, make sure the cards are not repeating the same description, and confirm that pagination does not lead to empty pages. If domains have different prices or use different offer only modes, verify that the data is not mixed up. A wrong price or domain name looks worse than the absence of advanced animation.

If the domains are grouped by niche, check the internal links. For example, a page for education-related domains should lead to relevant domains, not random names pulled from the entire portfolio. That kind of structure helps both the user and the administrator: it becomes easier to see which section is generating inquiries.

When It Is Better to Delay the Launch

Delay publication if the form fails the test, the email never arrives, the mobile version breaks the first screen, the copy still reads like an empty template, or the page loads with PHP warnings or JavaScript errors. These issues are easier to fix before launch. If traffic is already being routed to the domain, you can temporarily keep a simple page with a contact email while Nilam is being configured on a test URL.

A strong final review answers one question: if a potential buyer opens this page right now, will they understand the value of the domain, be able to submit an offer, and see a clear next step?

Security, Privacy, and the Real Transaction

Selling a domain may sound simple: the user submits an offer, the owner replies, and the parties agree. In practice, a domain transaction touches personal data, payments, domain transfer, ownership verification, and protection from suspicious inquiries. Nilam helps collect and manage offers, but it should not be treated as a complete legal and payment infrastructure.

Visitor Data and Transparency

The WordPress.org page for the free version specifically notes that when a domain page is displayed, it may use ipwhois.app for IP-based geolocation data, and that Appsero SDK collects basic telemetry only after the administrator gives explicit consent. Those details matter for privacy: if your site has a privacy policy, update it to reflect the actual data collected by the form and connected services.

Do not collect more than you need. If you are not using phone calls, do not make the phone field required. If geolocation is not necessary for the first-stage evaluation, do not bring it into the conversation as a negotiation point. The more transparent the form is, the fewer questions a legitimate buyer will have.

Escrow and Domain Transfer

The official Domain For Sale site mentions Escrow.com integration among the Pro features: an escrow purchase flow and invitations for buyers who already submitted an offer. That can be useful for a secure transaction, but in a plugin setup guide it is important not to mix the site's working features with instructions for purchasing the plugin itself. If the feature is available in your version, use it only after you have reviewed the legal and financial side of the deal.

Even when an escrow flow exists, the administrator still needs to verify domain ownership, the buyer's contact details, transfer terms, and the fee structure of the chosen service. Nilam may simplify the path from interest to inquiry, but the final decision still belongs to the domain owner.

Form Protection and Suspicious Offers

Google reCAPTCHA, form validation, email confirmations, and submission data all help reduce junk, but none of them guarantee that an offer is real. Treat submissions as suspicious if they come without a clear name, use disposable email addresses, contain only a partial message, try to move the conversation "urgently" into another channel, or ask for registrar details before any verification.

A good practice is to reply from the site's official domain, never send access codes, never change registrar contact data before the transaction is confirmed, and never open attachments from buyer emails without caution. These are not Nilam features, but they are directly related to the real-world use of a domain sales page.

Why the Page or Form May Fail, and How to Find the Cause

Nilam troubleshooting should move from simple to complex. There is no need to start by reinstalling the plugin, changing the theme, or editing files. Most issues come down to the display mode, cache, email delivery, style conflicts, reCAPTCHA keys, or incorrect shortcode placement. The section below is based on confirmed product features, support forum topics, and standard WordPress practice.

The Form Submits, but the Email Never Arrives

Symptom: the visitor sees a success message or the offer appears in the admin panel, but the administrator does not receive a notification. A likely cause is that WordPress email is not configured, the hosting provider is blocking delivery, the sender domain fails SPF/DMARC checks, or the message is landing in spam.

Check the offer list in the admin panel. If the record exists, Nilam completed its part of the workflow. Next, check SMTP, the administrator address, the email subject line, and the spam folder. If the record does not exist, the problem is closer to the form, validation, or reCAPTCHA.

The Background Disappeared or the Styles Broke After an Update

The free version's support forum includes a thread about a missing background after an update, and the changelog mentions background handling and CSS fixes. If the visual layer changes after an update, do not edit plugin files. First, clear the cache, resave the background settings, check the overlay, make sure the image is still available in the media library, and compare the page in guest mode.

If you are using a CSS optimizer, temporarily exclude the domain page from bundling and minification. On landing pages like this, a correct first screen matters more than squeezing every last kilobyte out of the asset pipeline.

The Shortcode Appears as Plain Text

Symptom: the page displays the shortcode itself instead of the template. The usual reason is that the code was inserted into a location where WordPress does not process shortcodes, or the builder is escaping the content. Use the Shortcode block, the Nilam/Elementor widget if it is available, or the standard page content area.

If the shortcode works in a normal post but not inside a theme template, the issue is not in Nilam. Check whether that specific theme area supports shortcode execution.

reCAPTCHA Blocks Submission

If the form stops submitting after reCAPTCHA is enabled, check the keys, the domain, the reCAPTCHA type, JavaScript cache, and console errors. Temporarily disable script optimization only on the domain page. If the form starts working after that, create an exclusion for the protection scripts or the Nilam page itself.

The Page Looks Fine for the Admin, but Bad for a Guest

This is a classic sign of cache, permission differences, or conditional style loading. Open the page in incognito mode, on another device, and after clearing the cache. If the guest version is stale, clear the site cache, CDN cache, and browser cache. If the difference remains, check whether the theme is loading styles only for logged-in users.

The Buyer Does Not Understand What Happens After Submission

This is not a technical error, but it does lower lead quality. Add a short explanation next to the form: the owner will review the offer, reply by email, and discuss the transfer terms. Do not imply instant purchase if the process still requires negotiation or a third-party escrow service.

When CodeCanyon Nilam Is the Right Choice

CodeCanyon Nilam is worth using when you need a controlled WordPress-based domain sales page rather than just an external marketplace link. The plugin fits especially well when the owner wants to control the copy, design, form, contact details, domain list, buyer offers, and SEO elements. The most useful pieces are the templates, shortcode, block, Elementor widget, form settings, reCAPTCHA, typography, color controls, portfolio display, and the admin inquiry list.

Before publishing, verify four things: the page opens correctly for guest visitors, the form saves the offer, the email reaches the administrator, and the mobile layout does not hide the important elements. Once those checks pass, you can move on to more refined improvements such as related domains, the SEO description, color styling, email templates, and spam protection.

If this guide has made it clear which display mode you need, which form fields matter, and how to test the result, you can get the CodeCanyon Nilam file and test it on a separate page or staging site. Do not start with your live homepage: set up one domain first, send a test inquiry, check the email, and only then roll the same workflow out across the full portfolio.