Yes — if you own or manage rental property, you need a website. But not for the reason most designers give you.
You don't need one to "establish an online presence." You need one because three specific jobs are currently being done badly by your phone: telling people what's actually vacant today, letting them book a tour without talking to you first, and proving to a stranger — a prospective tenant, a housing caseworker, an owner deciding whether to hand you their building — that you're a real company that will still be here next year.
A website that does those three things pays for itself. A website that doesn't is a brochure, and you were right to skip it this long.
I've built both kinds. The rest of this is what I've learned about the difference, most recently from building the operations platform and public website for Two River Development, a Philadelphia affordable-housing company managing hundreds of units.
"I'm already on Zillow, Apartments.com, and Facebook. Isn't that enough?"
No, and the reason isn't that marketplaces are bad. They're good at what they do. The problem is what you're renting from them.
On a marketplace, your unit sits in a grid next to every competing unit, sorted by an algorithm you don't control, with a "similar listings" rail underneath actively pulling your applicant to somebody else's property. You pay for that placement, and the day you stop paying, everything you built there disappears. You can't call the marketplace and ask for your traffic back.
A Facebook page has a different problem: nobody searches Facebook. Someone looking for a two-bedroom that takes a voucher types that into Google at 9:40 on a Tuesday night, and a Facebook page will almost never be the answer. Facebook is where people go once they already know your name.
And neither one does the fourth thing that matters. An owner with a twelve-unit building who is thinking about switching management companies will look you up before they call. They are not going to be persuaded by your Apartments.com profile.
So: keep the marketplaces. They're a channel, and a good one. Just stop treating a rented channel as your foundation.
"What should a property management website actually do?"
Five things. If it does these, everything else is decoration.
1. Show what's vacant right now — accurately. Address, rent, beds, baths, neighborhood, real photos. Not "contact us for availability." Not a PDF. Not last quarter's list.
2. Let someone book a tour at 11pm. Your phone is closed. The person looking for an apartment is not.
3. Take the application, or hand off cleanly to whatever takes it. Every extra step between "I want this unit" and "here's my information" costs you applicants.
4. Answer the questions your phone answers forty times a week. Do you accept vouchers? What's the application fee? Do you allow pets? How long does approval take? Every one of those answered on a page is a call you don't take.
5. Be findable at the unit level. One page per available unit, with its own address and its own photos, so Google has something specific to rank when somebody searches a neighborhood and a bedroom count.
Notice what isn't on that list: a mission statement, a hero video, a team-values section, a blog you'll abandon in March. Those aren't harmful. They're just not why the site exists.
"Why does every rental website's vacancy page go stale?"
Because somebody has to type it in twice.
This is the actual reason, and once you see it you can't unsee it. Your vacancies live in your leasing system — AppFolio, Buildium, Rent Manager, a spreadsheet, whatever you run on. Your website has its own separate list, in a CMS, maintained by hand.
So when a unit leases on Thursday, someone has to remember to go remove it from the website. When the rent on a unit changes, someone has to remember to change it in two places. When four new units come online the same week you're dealing with a burst pipe, nobody remembers anything.
Within about two months, the website's list is wrong. Then your team learns it's wrong, stops trusting it, and starts telling callers "let me check and get back to you" — which is exactly the phone tag the website was supposed to end. Now you're paying for a site that generates work instead of removing it.
Nobody is lazy in this story. The workflow is just broken by design.
"So what's the fix?"
The website reads from the system you already use, instead of keeping its own copy.
That's the whole idea. Your leasing platform is the source of truth. The website asks it what's available, on a schedule, and rebuilds itself around the answer. Nobody retypes anything, because there's nothing to retype.
For Two River, that pipeline runs every morning before the business day starts. The operations platform we built for them holds the live vacancy data; the website pulls from it, and every vacant unit becomes its own real page — its own address, rent, photos, and description, pre-rendered as actual HTML rather than a grid that only appears after JavaScript runs. When a unit leases, it drops off. When four come online, four pages appear. Nobody on the leasing team touches the website.
Two details from that build are worth stealing regardless of who builds yours:
- When the data feed can't be reached, the site keeps yesterday's listings instead of showing an empty page. A stale list beats a blank one, and both beat an error.
- The site refuses to publish an empty vacancy list. If the feed comes back with zero units, that's far more likely to be a maintenance window than a genuinely full portfolio, so the build declines to wipe the page. That guard exists because an automated daily rebuild will happily ship a zero-listing website at 6am and nobody will notice until lunch.
Neither of those is clever. They're the kind of thing you only add after you've imagined the 6am phone call.
"Do people actually book tours online, or do they still call?"
They do both, and the split matters less than the timing.
Calls come during business hours, when someone is already motivated enough to dial. Bookings come at night, on weekends, and during work hours when the person can't talk on the phone — which is a large share of the people you want. A booking link on a unit page collects the applicant who would otherwise have thought "I'll call tomorrow" and then not called tomorrow.
The second-order benefit is the one people underrate: a booked tour is a scheduled commitment with a time attached, which shows up in a calendar and can be reminded, rescheduled, and counted. "I'll swing by sometime this week" cannot be any of those things.
"How many pages does a rental website need?"
Fewer than an agency will quote you, plus one per available unit.
The core is small: what you do, what's available, how to apply, who you are, how to reach you, and the answers to your ten most-asked questions. That's most of the value, and it's maybe eight pages.
The per-unit pages are where the search traffic is. Nobody searches "Philadelphia property management company." They search a neighborhood, a bedroom count, and a price. A single "Available Housing" page can't rank for all of that. Fifty individual unit pages, each naming its own street and rent, can — and they cost nothing extra to produce once the listings feed is wired up, because they generate themselves.
Two River's site builds out to about 120 pages. Around twenty of those were written as pages. The rest generate themselves from data — one per available unit, one per property in the public rental portfolio — and they're the ones a search for a specific neighborhood and bedroom count can land on.
"Will a website help me get owners, not just tenants?"
Yes, and this is the half most rental sites forget.
Tenants and owners are two different audiences reading for two different things. A tenant wants to know if the unit is still available and whether you take their voucher. An owner wants to know whether you'll still be around in three years, whether you've done this before, and whether handing you their building is a decision they'd have to defend.
The owner audience is not persuaded by photography. They're persuaded by evidence: a portfolio page with real addresses, a page explaining exactly how you handle voucher inspections and payments, a team page with actual people on it, and a site that looks maintained. "Maintained" is doing a lot of work in that sentence. A site with a 2019 copyright and a dead phone number tells an owner more than any pitch deck will.
Same logic applies to the third audience nobody plans for: housing authority staff, caseworkers, and nonprofit partners who need to send someone your way. Give them a page they can forward.
"How much does a real-estate website cost?"
For a US-based rental or property management company, market rates in 2026 land in four bands. These are what the work generally goes for — not a price list, and any serious quote depends on the drivers further down.
$0–$2,000 — DIY on a template. Squarespace, Wix, or a WordPress theme you assemble yourself, plus the subscription. Real cost is your weekend. Fine if you have a handful of units and rarely advertise a vacancy.
$3,000–$8,000 — a custom brochure site. A freelancer or small studio designs and builds it properly: branded, mobile-fast, real content, basic search setup. No listings integration, so somebody maintains the vacancy page by hand. Four to six weeks.
$8,000–$25,000 — a site wired to your leasing platform. Live vacancy pages, one page per available unit, tour booking, an application path, and structured data so listings can be read as properties rather than as text. Six to twelve weeks. This is the band where the website stops being a cost center and starts removing work from your leasing team.
$25,000+ — website plus the operations layer underneath it. The site becomes one surface on a system that also handles your inbox, your reporting, and your leasing pipeline. Months, not weeks, and it's only worth it when the problem is bigger than the website.
What actually drives the number
Two quotes for "a rental website" can differ by 5x for legitimate reasons. The ones that move the price most:
- Whether your leasing platform will talk to you. Some expose a clean feed. Some require scraping, an intermediate system, or a paid API tier. This single question swings the estimate more than anything else on this list, and it's worth answering before you collect quotes.
- How many units, and how often they turn. Ten units turning yearly is a different build from three hundred turning monthly.
- Whether you have content and photos. Copywriting and photography are real line items. If every unit needs a description written, that's not a design cost, but you'll still pay it.
- How many audiences the site serves. Tenants only is one site. Tenants plus owners plus caseworkers plus contractors is four sets of pages and four sets of decisions.
- Voucher and affordable-housing complexity. PHA, Section 8, and local program pages carry compliance-sensitive language and often need review. That's slower than it looks.
- Migrating an existing site. Redirects from old URLs, preserving whatever rankings you have, and not losing the pages people already link to. Cheap to do at build time, expensive to fix later.
- Who maintains it afterward. A site your team can update costs more upfront and less every month after. A site only a developer can touch is the reverse.
What shouldn't cost extra
You should own the domain, the code repository, and the hosting account outright, at every band. If any of those sit in a vendor's name, the price you were quoted isn't the price you'll pay. And the site must load fast on a phone on a mediocre connection — most of your visitors open it standing outside a building.
Ranges only get you so far, because the leasing-platform question and the unit count change the answer more than any published rate card would suggest. If you want a real number, get a scoped quote on a call — bring your unit count, whatever leasing software you run on, and a link to your current site, and it's a thirty-minute conversation.
"How do I know if my current website is costing me money?"
Testable signals, in rough order of severity:
- Your vacancy page is wrong right now. Open it. Count the units. Compare against your leasing system. If they disagree, that's the whole article.
- There's no way to reach a specific unit by URL. If you can't text someone a link to that apartment, you can't run ads to it, and Google can't rank it.
- "Contact us for availability" appears anywhere. That's a form standing where information should be.
- No booking link. Every after-hours visitor is a lost lead you'll never see in any report.
- It takes more than three seconds on a phone. Test it on PageSpeed Insights, on 4G, not on your office wifi.
- Your phone number or address differs between your site, Google, and your marketplace profiles. That inconsistency quietly suppresses you in local search.
- Nobody on your team can update it without calling somebody. A site your team can't touch will be wrong within a quarter, guaranteed.
If three or more of those are true, the website isn't a marketing asset. It's a liability with a domain name.
Frequently asked questions
Do I need a website if I only own a few units?
If you have three units and they turn over once every four years, no — a Google Business Profile and marketplace listings are genuinely enough, and I'd tell you not to spend the money. The math changes around ten to fifteen units, or sooner if you're taking vouchers, because voucher-holders and their caseworkers are actively searching for landlords who accept them and there are fewer of you to find.
Can my website pull listings from AppFolio, Buildium, or Rent Manager?
Usually yes, one way or another — through a feed, an API, or an intermediate system that already talks to your platform. The right approach depends on what your platform actually exposes, which is worth checking before anyone quotes you. The principle holds regardless: one source of truth, and the website reads from it.
What if my listing feed goes down?
That's a design decision, and you should ask about it before you sign. The correct answer is that the site keeps serving the last known-good list and quietly retries. The wrong answer is an error page, or a page that goes blank. Ask any developer quoting you what their site does when the feed fails; the answer tells you a lot.
How often should the listings update?
Once a day, before the business day starts, covers nearly every rental operation. Real-time sounds better and rarely is — vacancy data doesn't change by the minute, and a site that refetches constantly is more failure modes for no additional leased units.
Should I build it on WordPress, Wix, or something custom?
Wix and Squarespace are fine for the brochure tier and will fight you on listings integration. WordPress can do it and needs ongoing maintenance you'll either pay for or forget. A modern static build is the fastest and cheapest to host, but it needs a developer to change structural things. Pick based on who's maintaining it in year two, not on what's cheapest in month one.
Do I need a separate site for tenants and owners?
No. Separate sections, one site. Two domains means two things to keep current, and one of them will rot.
Is it worth adding a chatbot?
Sometimes, and later than most vendors will tell you. Get the vacancy data right first — a chatbot on top of a stale listings page just answers questions wrongly, faster. There are also fair-housing constraints on what an automated system can ask a rental applicant, which is a legal review, not a feature toggle.
The honest version
Most rental websites fail for an unglamorous reason: they were built as a one-time deliverable and then required ongoing manual work that nobody had time to do. The design wasn't the problem. The copy wasn't the problem. The double data entry was the problem.
So the question isn't really "do I need a website." It's "will this website still be telling the truth in six months, without anyone remembering to make it?" If the answer is yes, build it. If the answer is no, you're about to pay for something that will quietly become a liability, and you'd be better off with a Google Business Profile and a phone that gets answered.
If you want to see what the first version looks like in practice — a site whose vacancy pages rebuild themselves every morning from the company's own operations platform — the Two River Development case study walks through the whole build.
And if you'd rather just talk it through against your actual portfolio and your actual leasing system, the contact form takes thirty seconds. We build real estate websites and the operations platforms behind them, and we'll tell you honestly if you don't need the second one yet.
