A Comparison Page Across Three Regulated Cities

A single-city page ages badly. A three-city page survives a rule change, because only one row moves.

Last updated: October 31, 2026

Every page that explains rules in one place has the same weakness. The place changes something, and every line on the page becomes wrong at the same moment. You usually find out from a reader, which is the expensive way. Put three places on one page with identical columns, and the same change costs you one row instead of a rewrite.

Key Takeaways

• One city is one point of failure. A rule change invalidates the whole page at once, including the parts that were still true.
• Three rows absorb the change. One row moves, two stay, and the page keeps working while you catch up.
• The columns must be identical. A page with different fields per city is three articles stapled together.
• Every line carries a date. Not the page's date — the date that line was checked.
• Status is a column, not a footnote. In force, proposed and pending are three different things and readers need to see which is which.

Why one city is not enough

A single-city page is a bet that the city holds still. It rarely does. Rules get amended, guidance gets reissued, an enforcement practice shifts without any text changing at all. When that happens, the page doesn't degrade gradually — it goes from correct to misleading between one update and the next.

The awkward part is that the reader can't tell. Your headline still looks confident, the numbers still look specific, and nothing on the page says it was last touched eight months ago. Some readers will trust it and be wrong. Others will spot the staleness and stop trusting the rest of your work, which is worse.

Three cities change the arithmetic of that failure. When one of them moves, one row is affected. You mark it, rewrite it, and the other two rows are still doing their job. The page stays useful through the period when you don't yet know the answer, which is exactly the period when readers need it.

There's a second reason, less defensive. Readers arrive already comparing. Somebody deciding where to operate is holding two or three places in their head at once, and a page that covers only one of them makes them do the work alone, in a different tab, with no shared structure. Three rows give them a shape for a comparison they were going to make anyway.

localsbnb.com keeps Airbnb, Booking.com, Agoda and Trip.com on one calendar, which matters here for a practical reason: a host running units in more than one of those cities is already looking at one screen for the business. A page that treats the cities separately is describing a business that person doesn't run.

Three rows, the same columns

The columns are the whole design. Four of them, applied identically to every city.

What the rule governs. The subject, not the answer. Nights, registration, zoning, a fee, a density cap. Say what kind of question this place is answering.

Who decides. The level of authority and the body. This is the column that saves the most reader time, because it tells them who to ask and who can't help.

Status now. In force, proposed, or pending. Three words, and the cell should hold one of them plus the date it was set.

What a host does next. A single action: read the current text, ask the authority, wait for the vote, keep a document. Not a paragraph.

Fill every cell to the same depth. If one city gets a sentence and another gets an essay, the page stops being a comparison and becomes a page about your favourite city with two appendices. That's a structural failure, not a writing one, and readers feel it even when they can't name it.

One practical note on getting the rows right. Importing listing data from Airbnb brings the address across along with the title, photos and capacity. That address is what tells you which jurisdiction a unit actually sits in, and it's the first thing a comparison page has to get right. A unit near a border is the case that catches people, and it's the case a reader will write to you about.

Dating every line

A date on the page is not the same as a date on a line. The page date tells a reader when you last edited anything. The line date tells them whether that particular sentence is current, and those are different questions.

So put a checked date in every row, and make the page-level date equal the newest line rather than the oldest. If a row is older than the rest, say so where the reader can see it, not in a footnote at the bottom.

Never round a date up to a month or a year. "2026" tells a reader nothing they can use, and it invites them to assume the best. A precise date that's four months old is more trustworthy than an approximate one, because it lets them judge.

The status word and the date have to travel together. "Proposed, checked 31 October 2026" is a complete thought. "Proposed" on its own is a claim with no expiry, and a proposal can die quietly without anyone updating the page.

Keep the source next to the date, in whatever form is shortest — the name of the document, the body that issued it, a link. Not because every reader will check, but because the ones who do are the ones who'll tell you when you're wrong.

What not to compare

Some things look comparable and aren't.

Don't put numbers that measure different things in the same column. A limit on nights, a registration requirement and a cap on the number of units are three different instruments. Stacking them in one column invites a reader to rank them, and the ranking will be meaningless.

Don't rank at all. A table with a "best" column is an opinion wearing a table's clothes, and it dates faster than any rule. Describe status and let the reader decide what matters for their situation.

Don't mix a proposal with a rule in force without labelling both. This is the single most common error in pages like this, and it's the one that gets screenshots taken of it.

Don't fill a cell you can't source. An empty cell with a date is honest. A confident sentence with no source is a liability that will be quoted back at you at the worst moment.

And don't put your own performance in the same table. Occupancy in one city and occupancy in another are answering different questions, with different demand, different seasonality and different stock. That comparison belongs in your dashboard, where it's labelled as yours.

FAQ

How often should the page be updated?

Follow the sources rather than a calendar. A row gets a new date when its source changes, and the page date catches up. On top of that, a scheduled review catches the quiet changes — enforcement practice, guidance notes, a proposal that died without an announcement. Quarterly is a workable rhythm for most pages, and the review is fast if every row carries its own source.

Can the page say which city is easiest?

It can say what each place requires and what status each rule is in. It shouldn't say which is easiest, because that depends on the unit, the building, the licence you can get and the demand you're chasing — none of which the page knows. A ranking also breaks the moment one city moves, which is the problem the page exists to solve.

What if one city has no rule yet?

That's a status, so write it as one: no specific rule identified, checked on a date. An empty cell reads as an oversight. "Nothing found as of this date" reads as work, and it's the more useful thing for a reader who's deciding whether to wait.

A comparison page isn't a traffic play or a content asset in the usual sense. It's a maintenance commitment with a URL. localsbnb.com won't write the rows, and it won't keep the dates current. But if your units sit in more than one of those cities, the calendar and the channel data behind them already live in one place, and that's the part of the comparison you can verify yourself.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. Rules on short-term letting differ by jurisdiction, change without much notice and are often still being drafted; nothing here states a requirement, a threshold or a fee for any place. Confirm the current position with the competent authority in each city before you rely on it.