A branch website that ranks in its own city, and stays consistent

A branch mortgage website has a different problem from a loan officer’s personal site. The loan officer’s site has to convert a referral who already knows the name. The branch site has to be found by people who do not know any of the names, carry a page for every originator without any of them touching a website builder, and stay consistent as the roster changes. That is a structural problem, and it is solved with records and generation rather than with pages and diligence.

This article covers the structure that works: what a location page should contain, how profiles are generated, how programs are inherited rather than repeated, and the governance that keeps twenty pages in step eighteen months later. It is about websites. It is not lending, licensing or financial advice, and it takes no view on what your disclosures should say, which is your compliance team’s call.

The shape of a branch site

Five page types carry a branch business, and almost everything else is supporting material.

The branch location page. One per office. This is the page that has to rank for the city and the page a borrower reads to decide whether to walk in or call.

The city or area page. One per town you genuinely serve from that office, where you can say something true and specific. Fewer than you think.

The originator profile. One per licensed person, generated from their record.

The program page. One per program originated, defined once for the company and surfaced on the branches and profiles that place it.

The roster. The index of people, generated, not typed.

Everything else, about, contact, articles, legal, is the same as any other site. The five above are where branch sites succeed or fail.

The location page

What makes it specific

A location page that is the company description with a city name substituted is the definition of the thin, copied content Google’s helpful content guidance describes. It is also useless to a borrower. The fix is to write what is only true here.

The people. Who works at this office, with links to their profiles. This is the single strongest differentiator, because the roster is genuinely different at every location and it is the thing a borrower most wants to see.

The programs originated here. Not the company’s full catalogue. What this office actually places, which is often narrower and occasionally broader than the corporate list.

The area served. The towns, counties and neighbourhoods, named the way local people name them. This is where local vocabulary belongs, and it is far more useful than a radius.

How the office works. Appointments or walk-ins, parking, which entrance, what to bring, the hours that are actually kept. Unremarkable information that is exactly what someone reads before visiting.

Something true about the market. Not a statistic you cannot source. The kind of observation a branch manager makes: the mix of purchase and refinance work, the sort of properties, whether business comes mostly from agents or from past clients. Two honest paragraphs here do more than a page of generic copy.

The technical part

Mark the office up with local business structured data, and make sure what the markup says matches what the page says, because structured data that disagrees with the visible page is a problem rather than an advantage. Name, address, phone, hours, and the identifiers your compliance team requires.

Keep the address, phone and hours as data in the branch record, rendered into both the page and the markup. That is the only way they stay in agreement, and it means a change of hours is one edit.

What not to do

Do not create a location page for a place you do not have an office in. A page implying a presence that does not exist is a credibility problem and, depending on how it is worded, potentially worse than that. If you serve a town from a nearby office, the honest page says so, and it will still rank if it is the useful page about that town.

Profiles, generated

This is the part that decides whether a branch site is maintainable.

One record, many renderings

Each licensed person has a record: name, title, identifier, licensed states, programs, photograph, contact details, a short biography, a link to a personal site if they have one. From that record the site generates the profile page, the entry in the branch roster, the card on the location page, the author box if they write, and the identifier lines in the compliance block.

Nobody edits a page. They edit a record. That single rule removes almost every drift problem a multi-person site has.

Incomplete records do not publish

If the record is missing an identifier or a state list, the profile does not go live. This feels strict until the first time it stops a new hire’s page from publishing without an identifier on a Friday afternoon.

The same applies in reverse. When somebody leaves, one change to one record removes the profile, the roster entry, the location card and the author attribution together. A departure handled in one place is a departure handled correctly.

What a profile should carry

A borrower on a profile page is deciding whether to contact this person. They want to know what they originate, where they are licensed, how long they have been doing it, and how to start. The photograph matters more than anyone likes to admit, and a real one taken in the office beats a stock portrait every time.

Include the programs they place, each linking to the program page. That is the internal link that turns a roster into a navigable site, and it is the path a referral follows.

Programs, inherited

A company originates a set of programs. A branch originates some of them. A person originates some of the branch’s.

Define each program once, as a page, at company level. Then let branches and people reference the programs they place. The branch page lists its programs from the branch record. The profile lists that person’s from theirs. Every one of those links points at the same program page.

The alternative, a copy of each program description on each branch page, produces a site where twelve pages say almost the same thing, which is bad for search and worse for maintenance. Programs change. A copied program description changes in one place and stays wrong in eleven.

Where local detail belongs

Sometimes a program genuinely works differently at a branch, usually because of the market rather than the product. That belongs on the location page as a short note linking to the program page, not as a forked copy of the program.

The city page, done properly

City pages are where branch sites most often go wrong, because they are easy to generate badly and hard to write well.

What a good one contains

Why you are in this town. An office here, originators who live here, a long relationship with agents here, or a specialization that matters here. If the honest answer is “we are not, but we serve it from the next town”, write that, because it is still a reason for the page to exist and it is verifiable.

Who covers it. Named people with links to their profiles. Local searches are often looking for a person as much as a company.

The property mix, described. What people are actually buying here, in ordinary words. Older housing stock, a lot of new build, a rental market, seasonal properties. This is the paragraph a local reader uses to decide whether you know the place.

How business is done here. Whether transactions run fast or slow, what agents in the area expect, anything about timelines that differs from your other markets. Be careful to describe, not to promise.

The practical next step. Same as everywhere: one obvious way to start, one lower-commitment way to ask.

How many to write

Write the first three properly and see whether they do anything. A branch that publishes three genuinely local pages and finds two of them producing inquiries has learned something worth acting on. A branch that publishes forty templated pages has learned nothing and created forty pages to maintain.

The failure pattern is recognizable from the outside: pages whose only differences are the place name and a rearranged sentence. Readers notice, and the helpful content guidance is explicit that content made primarily to rank rather than to help is the wrong approach.

Keeping them from going stale

City pages rot faster than location pages because they describe a market rather than an office. Review them annually, and whenever the person who covers the area changes. A page naming an originator who left two years ago is worse than no page.

Reviews and testimonials on a branch site

Every branch wants social proof and most branch sites handle it badly, either by embedding a third-party widget that slows the page and sends data somewhere, or by publishing quotes that cannot be substantiated.

The structural answers are simple. Present reviews in your own markup rather than in an embedded widget, so they are fast, accessible and styled like the rest of the site. Keep whatever substantiation your compliance team requires. And be careful with schema: marking up reviews for rich results carries requirements about what may be marked up and where it came from, and getting that wrong is a worse outcome than not having stars.

If the only quotes you can publish are illustrative rather than attributable, say so plainly on the page. A clearly labeled illustration is honest. An unlabelled one that turns out to be composed is the kind of thing that ends up in a complaint.

What to measure, per branch

Company-level reporting hides branch-level problems. Four numbers, per location, monthly.

Inquiries from this location page. Not site-wide. If one branch produces nothing, that is a page problem, a market problem or a routing problem, and you cannot tell which from a company total.

Which profiles are being read. A profile with no traffic is usually a profile nobody links to, which is usually a roster or programs problem rather than a person problem.

Which city pages earn attention. The honest signal about whether to write more of them.

Time from inquiry to first contact, by branch. Nothing to do with the website, and the number that most decides whether the website appears to work.

Who owns each of those numbers

The branch manager owns the first and the fourth, the person running the site owns the second and the third. Numbers without an owner get reported and never acted on, which is how quarterly website reviews become a slide nobody reads.

Governance that survives eighteen months

Documented governance is not governance. What works is constraints in the system plus a rhythm somebody owns.

Constraints

An incomplete record cannot publish. Identifier, states, title.

A page cannot exist outside the layout. No campaign page without the compliance block.

Programs cannot be forked. A branch references a program, it does not copy one.

Addresses, hours and phone numbers live in one record each. Rendered into pages, markup and the footer from there.

Rhythm

Monthly: the roster is checked against reality. Arrivals, departures, title changes. Ten minutes, and it is the check that prevents the most embarrassing errors.

Quarterly: each location page is read by the person who runs that office. They are the only ones who will notice that the hours changed in March.

Quarterly: compliance reads the rendered block on a profile, a location page and a program page.

Annually: the city page list is reviewed. Which of these are earning their place, which should be written properly, which should go.

Speed, on a phone, in a town

None of the structure matters if the page does not open. Branch pages are opened on phones, often from a search done in a car, and Google’s page experience guidance treats that responsiveness as part of the quality picture.

The practical rules are the same as anywhere else and are more easily broken on a branch site, because branch sites accumulate widgets: a map embed, a review badge, a chat tool, a scheduling widget, each loading its own script. Four widgets is how a fast site becomes a slow one without anyone deciding to make it slow.

Prefer a static map image linking to the mapping service over an embedded interactive map. Prefer your own review presentation over a third-party badge. Load anything heavy only when it is needed, and audit the list of third-party scripts every quarter, because they arrive quietly.

Moving an existing branch estate onto this structure

Very few branches start from nothing. The usual situation is an estate of pages built over years by different people, some of them good, and the question is how to get to the structure above without a six month project.

Inventory first. Every live page, what type it is, who last touched it, whether anything links to it. Most branch estates contain pages nobody knew were live.

Records before pages. Build the people and branch records first, even while the old pages are still serving. The records are the asset; the pages are a rendering.

Convert one location completely. One branch, all its pages, end to end, before touching the others. A single finished example settles arguments that a specification never will, and it exposes the awkward cases early.

Keep the addresses. Any page that has been live and has links pointing at it should keep its address or redirect to the page that replaces it. This is the part that is cheap to do during a rebuild and very expensive to reconstruct afterwards.

Retire deliberately. Pages that should not exist get removed on purpose, with a redirect to the nearest useful page, rather than left live because nobody is sure.

When a branch wants its own thing

The recurring tension on a branch site is that a producing branch manager wants something the template does not do, and the company wants consistency. Both are reasonable.

The way through is to decide in advance what is local and what is not. Copy, photography, the programs listed, the area served, the market commentary: local, and changeable by the branch. Layout, the compliance block, the program definitions, the identifier rendering, the page types themselves: company, and not changeable locally.

Write that division down and build it into who can change what. A branch that can change the things that make it distinctive rarely asks to change the things that must not vary.

For the compliance side of this structure, the compliance block covers how identifiers are generated and governed, and if a branch is moving from an old site, migrating a mortgage website covers keeping the rankings you already have.