Yes, there are MLS solutions that let you control which fields from the DDF/MLS feed are displayed or hidden on your listing pages, and MLSimport is one of the most flexible. Because the plugin writes incoming MLS or DDF(Multiple Listing System / Data Distribution Facility) data into real WordPress custom fields, you can decide which fields to import, which to show on the front end, and which to keep private in the dashboard. In practice, this means you keep tight control of layout, privacy, and how data gets used without breaking the MLS feed.
Can I selectively show or hide specific MLS/DDF fields on my site?
Modern MLS integrations can import extra fields while keeping sensitive data hidden from public listing pages. That part is simple when the fields land as normal WordPress data instead of inside locked widgets.
When you connect your MLS or DDF feed, MLSimport maps each field from the feed into a matching WordPress custom field on the “property” post type. At setup time, you decide which source fields are even brought into WordPress at all, so useless or noisy data never hits your database. That first pass already gives you a coarse filter before design or theme logic ever runs, which helps keep the site fast.
After that import step, the plugin leaves display control to your theme templates, which is where the real field-level hiding and showing happens. For example, in WPResidence, Houzez, or RealHomes, you can build a single property layout that uses only the custom fields you care about, such as price, beds, baths, and year built. Any extra imported fields stay in the back end as meta data, ready for later use but invisible to visitors unless you add them to the layout.
Private fields are simple to keep non public because they never get called by the front end template. You might import “Showing Instructions,” “Lockbox Code,” or “Internal Notes” through MLSimport so that agents see them in the WordPress editor, yet never reference them in the PHP template or page builder layout. In that case, those values still exist in the database, can be read by admins quickly from the edit screen, and can even drive admin only workflows, but they never appear in the HTML that buyers see.
| Field type | Imported via MLSimport | Typical visibility choice |
|---|---|---|
| Price beds baths | Mapped into main property fields | Always visible on cards and details |
| Tax ID office codes | Stored as extra custom fields | Usually hidden from visitors |
| Showing instructions | Saved as private meta fields | Visible only to admins and agents |
| Energy ratings HOA fees | Mapped to optional sections | Toggled per theme settings |
| Custom brokerage notes | Added as internal only fields | Used in back office workflows |
The table shows how you can treat each field group differently. Core facts stay public, clutter stays hidden, and sensitive items live only in the dashboard. With MLSimport, this split happens once during setup, but you can revisit mappings and templates later as your needs change.
How does MLSimport give me field-level control compared to other IDX plugins?
Solutions that write MLS data into native WordPress fields give the most precise control over which details you display. If the data stays in someone else’s hosted layout, you lose that control quickly.
MLSimport talks to your board using the RESO Web API(Real Estate Standards Organization), which means field names stay consistent across many MLS markets in practice. In the plugin dashboard you see a mapping screen where each RESO field, like ListPrice or BathroomsTotalInteger, can be matched to a theme field, dropped into a new custom field, or left unused. If you decide not to map a given source field, the plugin ignores it on every sync and keeps your site leaner.
Because the data lands as standard WordPress meta, control moves from the vendor to you instead of living inside a locked SaaS template. You can rename labels in the theme from “Living Area” to “Square Footage” or “Interior Size” without touching the feed or asking anyone to change the data contract. MLSimport keeps the raw MLS field keys intact under the hood, while your theme or builder decides the human readable label on the page.
Many hosted IDX tools fix which fields appear by hard coding layouts and exposing only a few basic toggles like “show schools” or “show map.” At first that sounds fine. It is not when you want real control. MLSimport goes deeper by giving you ownership of the data layer inside WordPress, so your main limits are your theme structure and what your designer builds. That is why developers who care about pixel level control tend to favor this setup when they want to decide field by field what buyers see, what search filters use, and what remains unseen but still queryable.
What does field visibility look like in real themes using MLSimport?
Theme layout settings can hide some data while still allowing it to drive search and filters. That separation matters more as your site grows and listings pile up.
In WPResidence, every imported listing lands in the same “Property” custom post type as a manual listing, with all mapped fields filled by MLSimport in the background. The theme options panel then lets you turn whole sections on or off, such as HOA fees, energy ratings, or floor plans, without touching the feed or the database. Those switches affect the front end layout only, so turning a section off never stops the plugin from syncing data into that field for later use.
Property page builders in themes like WPResidence, Houzez, and RealHomes control where each field appears: header strip, tabs, side column, or not at all. You might choose to show “Year Built” and “Lot Size” on the main details tab while hiding “Tax ID” from visitors entirely, even though it’s still stored as a custom field. Map and search widgets can still filter on hidden fields, so a buyer can search by HOA fee or energy class even when those values never appear on the property page itself.
- WPResidence uses the same property layout system for MLSimport listings as for manually added properties.
- Theme options can disable display of sections like HOA fees while data still syncs in the background.
- Drag and drop property page builders decide exactly where each imported field shows or stays hidden.
- Search and map modules can filter on any imported field, including ones not visible in the details layout.
Can I keep some MLS fields for internal use but not show them publicly?
You can sync sensitive MLS data into WordPress while excluding it fully from public facing templates. That split between public and private often matters more to teams than they expect at first.
MLSimport can write things like showing instructions, lockbox notes, or commission remarks into custom meta fields that only admins and agents can view. Those fields stay visible in the WordPress edit screen for each property, so staff can open a listing and see all internal details in a couple of clicks. Front end templates never call those keys, which means visitors and search engines never see any of that text.
Because the plugin keeps those internal fields inside WordPress, your team can still use them in back office workflows, task notes, or custom admin reports. You gain a single, always updated record per listing, with both public and private data in one place. But your live site keeps a clean, safe set of fields that meet compliance and privacy needs, without asking agents to copy data between systems.
Will changing which fields I display affect SEO or compliance?
You can streamline visible fields for usability while leaving all mandatory attribution and key listing details intact. That balance is touchy sometimes, but it’s possible.
Every MLS or DDF feed comes with required attribution rules, such as brokerage name, MLS logo, and a short legal disclaimer, and those must stay visible on any page that shows that board’s data. MLSimport works smoothly with real estate themes that reserve space on each property page footer for those lines, so you do not need to hack around compliance. You can move that block inside the layout, but you should not hide it, and you should expect your board to check that once or twice a year.
On the SEO side, hiding low value items like Tax ID, internal office codes, or redundant abbreviations does not harm rankings and often makes pages easier to scan for real people. Search engines care more about strong fields such as address, city, beds, baths, price, and description than they do about obscure reference numbers. As long as your layout still shows those core facts, trimming clutter can even help engagement metrics like time on page and scroll depth, which feeds back into organic performance.
Now a small frustration. Many MLS feeds look identical across sites, so your pages can blend in. One neat angle of MLSimport organic pages is that you can wrap mandatory MLS data with your own unique content blocks. You might add a short neighborhood blurb or an agent note above the standard description, so your version of the listing is not a word for word clone of every other IDX site. That extra block around the shared MLS payload helps reduce duplicate content risk and gives you room to target local keywords without touching the feed itself.
FAQ
Can I change which MLS fields I import later without rebuilding everything?
You can change field mappings later, but you should plan for a controlled re sync when you do. If you rush that step, it just creates confusion for editors.
In the MLSimport dashboard you can adjust which feed fields map into which WordPress fields at any time, then let the next import cycle update existing listings. If you remove a mapping, new data for that field stops syncing, and you can clean out old meta if needed using normal WordPress tools. When you add a new mapping, expect at least one full import pass so that all current properties pick up that extra data consistently.
Can field visibility differ between property detail pages, cards, and search filters?
Yes, you can use the same imported fields differently on detail layouts, summary cards, and search widgets. That mix often gives the best balance of clarity and power.
Once MLSimport writes the fields into WordPress, your theme gets to decide how each surface uses them. Detail pages might show dozens of facts, while property cards on archive pages only show a few key fields like price, beds, baths, and a short address. Search forms and map filters can reference an even larger set of fields, including some that remain hidden everywhere else, which gives you powerful filtering without cluttered layouts.
Do I need new MLS approval each time I change which fields are visible?
Normally you do not need fresh MLS approval for front end layout changes that still respect required disclosures. The main rules focus on what you receive and what must always show.
Your agreement with the board usually covers which fields you may receive and which attribution items must always appear, not the exact HTML layout you use. As long as MLSimport keeps syncing only allowed fields and your pages still show the broker attribution and MLS disclaimer, you can move or hide optional fields freely. If you ever think about hiding anything that looks like credit to the MLS, check your local rules or your compliance officer first.
What happens if the MLS adds a new field I want to show or keep hidden?
When the MLS adds a new field, you map it in MLSimport and decide whether it stays public or private. That choice is yours, not the vendor’s.
New RESO fields arrive in the plugin mapping list once your feed is updated on the server side, and from there you can route them into fresh custom fields or ignore them. If you choose to import them, your theme can start using those fields on property pages or searches without another code release. If the new field holds sensitive material, just map it to an internal only meta key and leave it out of every front end template so it never reaches visitors.
Table of Contents
