One job per URL, said like a person
A service page has one job: tell a buyer what you do in that line of work, who it is for, and what happens next. If the page is “web development”, it should not also try to close ERP, a mobile app, and a retainer. Those are other URLs. Mixing them feels efficient in a committee. It reads as a brochure that cannot choose, and search engines treat it that way.
On an ASP.NET site the temptation is to build one handsome template and pour every offering into the same blocks. The template is fine. The pouring is not. Each service needs its own title, its own H1, its own first paragraph, and its own links out to the work and the writing that support it. Shared chrome — header, footer, a contact strip — is not the same as shared copy.
Write the job as a sentence before anyone opens the view. “This URL should make a Kochi manufacturer confident we can build the public site and the forms they need.” If a second sentence starts with “also we do”, that also belongs on another slug. One job per URL is not a slogan. It is how you stop a /services dump from competing with itself.
Buyers in India still search like buyers. They type the work plus the place, or the work plus the stack, or a problem they can already name. Your page should look like an answer to one of those, not like a tag cloud. If you cannot say which search the page is for, you do not have a service page. You have a category poster.
Titles, H1, and the first paragraph
The title tag and the H1 should be the same idea in the same words, give or take a brand suffix. If the title is “ASP.NET web development for business sites” and the H1 is “We craft digital experiences”, you have lied twice: once to the result page and once to the human who clicked. They will bounce. They should.
The first paragraph should repeat the job in plain English. Not a mission. Not a list of industries you once mentioned in a meeting. What you do, for whom, in language a non-marketer can repeat to a partner. Curly slogans waste the only sentences that get read on a phone in traffic.
On ASP.NET this is not a plugin setting. It is the view, the layout, and the meta you render on purpose. If title, H1, and Open Graph are three different stories because three people edited three files, fix the files. Do not add another SEO app that guesses. A Razor page can be exact. That is an advantage. Use it.
Keep one H1. Subheads can be H2. Do not hide the H1 in a slider that loads last. Do not replace it with a logo. Do not write an H1 that is a paragraph. If you need more words, that is what the first p is for. Search is not confused by short headings. Humans are confused by long ones that still say nothing.
How /services pages should work on this stack
Each service is a URL with a stable slug. /services/web-development stays /services/web-development. You do not rename it because a designer preferred “digital” this quarter. Redirects exist for real retirements, not for mood. If you already have web development as a live service, that page should be the canonical place for that job. Blog posts and knowledge articles point at it. They do not invent a second “web” landing page that fights it.
The page should say what is in scope and what is not. A web development page that never mentions CMS versus a custom ASP.NET public site forces the buyer to guess. Guessing becomes a call you did not want, or no call. Write the split. Link the deeper explanation. Then stop. You do not need a novel. You need a page that can be scanned and still be true.
Include a next step that is a form or a phone, not a maze. Service pages that end in “learn more” to another service page are how people leave. One primary action. Secondary links to writing and related services are fine if they look like related, not like you are afraid to choose.
We rebuilt this site as a custom ASP.NET application because the old WordPress install could not carry the content model. That history is in ASP.NET Core for business websites. The lesson for service pages is narrower: you own the HTML. There is no excuse for a missing H1, a duplicate title, or a body that is three screenshots and a form.
Internal links that a crawler and a human can use
Internal links are how you tell both audiences which page is the service and which page is the explanation. A knowledge article on vitals should point at the service that will fix the public pages. A blog post on the stack should point at the service, not only at itself. The service should point back at one or two pieces of writing that make the claim cheaper to believe.
Do not build a footer that lists every URL you have ever published. That is a sitemap wearing a nav. Link from the sentence that needs the other page. “Speed on public URLs” can point at Core Web Vitals without turning this article into a vitals lecture. The service page can hold the commercial claim; the knowledge page can hold the metric.
Avoid orphan services. If /services/erp-solutions is never mentioned from a relevant article, you are hoping the result page will do all the work. Sometimes it will. Usually it will not, especially when the article ranks and the service does not. Join them on purpose. That is cheaper than another round of title tags.
Also avoid circular “related services” blocks that only exist to look busy. Three honest links beat twelve badges. If two services should not be sold together in the first meeting, do not pair them in the template. Templates that auto-relate everything teach Google that nothing is distinct.
What ranking actually asks of the copy
Useful copy on a service page is specific and bounded. Who you work with. What you will not take. What the first month looks like. What the buyer must bring. Kerala SMEs do not need another paragraph about innovation. They need to know whether you will sit with the person who enters orders, or only with the person who approved the budget.
Write objections you actually hear. “We already have a site.” “We are on WordPress and it is fine except the forms.” “We need this to rank in Kochi and still look like us.” Answer those on the page. A FAQ block is allowed if it is real questions, not keyword stuffing. Fake questions waste space and trust.
Do not invent clients or rupee totals to look established. If you have a public project, name the work, not a fantasy invoice. If you do not have a public project in that line, say how you work and what you will inspect before you quote. Honesty ranks slower than fiction in some briefings. It survives a sales call.
Language should match the search without becoming a chant. If the page is ASP.NET web development, say ASP.NET where it is true. Do not hide the stack because a brand deck preferred “digital”. Do not repeat the stack in every sentence because a tool said density. People notice both lies.
A table for the URL, not for the brand deck
| Element | What good looks like | What we still see |
|---|---|---|
| Title and H1 | Same job, readable on a phone result | Brand slogan in one, keyword pile in the other |
| URL | One slug, one service, stable | /services plus a campaign parameter forever |
| First paragraph | Who it is for, what you do | We are passionate about excellence |
| Internal links | From the sentence that needs them | A grid of every page you have |
| Next step | One form or phone | Learn more, then learn more |
Print that table and walk your /services list. The pages that fail it are the pages that should be rewritten before you buy another audit PDF.
ASP.NET details that are not a CMS plugin
Canonical tags should match the live URL, including https and the host you actually want. Trailing-slash policy should be one policy. If both /services/web-development and the slash variant render, pick one and redirect the other. This is routing and middleware, not a feeling.
Index the service pages. Do not noindex them because someone copied a staging layout. Do not put them behind a surprise query string. Do not serve a thin teaser and hide the real copy in a tab that never reaches the HTML. If the crawler cannot see the paragraph, it is not on the page.
Images need width, height, and a file size a mid-range Android in Kerala can finish. That is part of Core Web Vitals, and it is enough said here: fix the money URLs, then stop treating Lighthouse as a product strategy. A service page can be a little slower than a blog home and still rank if it is the clearer answer. A service page that is fast and empty will lose to a slower page that answers the job.
Pagination, filters, and “load more” are usually wrong on a service index. You do not have five hundred services. You have a handful. List them. If you add a filter because the design system had one, you have added a crawl puzzle for no buyer.
The /services index is a map, not a second homepage
The index should help a human pick a door. Short lines, distinct jobs, links that go to the pages you just made honest. It should not repeat the company manifesto. It should not rank for every industry noun you can spell. If the index starts winning queries that belong to a child page, the child page is too thin or the index is too greedy. Fix the child.
Do not launch a /services/digital-transformation page because a competitor has one. If you cannot write one job and one next step, you do not have that service. You have a heading. Headings that do not map to delivery are how you win a click and lose the call.
When you add a real service, add the page, the nav item, and at least one piece of writing that links to it with a reason. Shipping the view without the links is how the URL sits in the sitemap like a rumour. Sitemaps do not rank. Sentences do.
What we refuse to do to “make it SEO”
We will not stuff city names you do not serve. We will not publish twenty location pages that differ by one noun. We will not hide an H1 and then buy a tool to report that the H1 is missing. We will not turn the service page into a blog so it can be “more words”. Words that do not serve the job are a second page, or they are deleted.
We will not make vitals the whole project. Public pages should not jump and should not block the tap on Call. After that, go back to the title, the H1, the one job, and the links. That is the work that still moves a /services URL on an ASP.NET site in 2026.
If you want that work done as a build, it sits in web development, on the same stack we argued for in ASP.NET Core for business websites. Bring the live slugs and the queries you already have impressions for. We will rewrite the pages that already almost rank before we invent new ones. New URLs are easy. Honest ones are the scarce thing.
A last test you can run without us: open the service page on a phone, cover the logo, and ask a colleague what the company does and what they should do next. If they cannot answer, the crawler is not the mystery. The page is. Fix the page. Then check Search Console. Then, if a money URL is still poor on mobile, read the vitals note and fix images and third parties. In that order. The other order is how you get a fast empty page and a quiet inbox.