The strongest project pages are first-hand evidence. They show what the business actually does rather than repeating generic claims such as “we provide a high-quality service in your area”.
Key takeaway
Do not publish a URL for every job. Publish a standalone project only when the evidence and learning make the page independently useful.
Why real project content can be valuable
A real project can provide things that a generic service page often cannot:
- original photographs;
- real product or service details;
- evidence of practical experience;
- specific customer questions;
- constraints and decisions;
- real local context;
- a supported outcome;
- a genuine testimonial where permission/public status allows it.
That can help future customers understand what the business is capable of. It can also support the wider website by linking evidence back to the relevant service and location pages.
GOOGLE GUIDANCE
Google's people-first content guidance encourages original information, first-hand expertise and content created primarily to help people. That does not mean a project page automatically ranks well. It means genuine first-party evidence is a stronger foundation than a templated page created simply to target another keyword.
Not every job deserves a URL
The easiest way to create thin project spam is to turn every completed job into a new page with the same structure and only the town or product name changed.
Instead, qualify the project.
Strong candidate for a standalone page
A project may justify its own URL when several of these are true:
- useful original photographs exist;
- the product/service is interesting or commonly researched;
- there was an unusual challenge or constraint;
- the location adds meaningful service context;
- the customer asked a useful question that others may also have;
- the project demonstrates an important service capability;
- a genuine testimonial can be used appropriately;
- the outcome or lesson can be supported by evidence;
- the page can link naturally to an important service or location owner page.
Maybe use as a section or portfolio item
A routine job with one or two useful photos may still be useful, but perhaps as:
- a portfolio card;
- a section on a service page;
- a photo gallery entry;
- a social post;
- a Google Business Profile update;
- an example inside a broader guide.
Not worth a standalone page
Do not create a new URL when the project has:
- no meaningful evidence;
- no useful photographs;
- no distinct customer problem;
- no lesson or detail beyond “we did another job in this town”;
- substantial overlap with existing project content.
This is a judgement framework, not a percentage SEO score.
Capture evidence while the job is happening
A project page is much easier to write when evidence is collected during the work instead of reconstructed months later.
Useful notes can include:
- date or approximate project period;
- service performed;
- product/model where relevant;
- number of items;
- important dimensions or materials where useful to customers;
- assembly/installation time where recorded accurately;
- unusual access or workspace constraints;
- customer question;
- before/during/after photographs;
- outcome that can be directly observed;
- public or customer-approved review/testimonial;
- non-sensitive location context.
Do not create facts later because the page feels too thin. If the evidence was not recorded, say less.
Photography is first-party evidence
Real images can demonstrate workmanship, scale and context in a way generic stock photography cannot.
For home-service businesses, photography also creates privacy responsibilities. Before publishing, consider whether the image reveals:
- a house number;
- a vehicle registration;
- a customer or child;
- personal photographs or documents;
- identifiable possessions;
- a private address or unique property detail.
Get permission where the customer, property or testimonial is identifiable. Crop or exclude unnecessary private detail.
Structure the project around usefulness
A good project page is not a minute-by-minute diary.
A useful structure is:
- What the customer needed.
- What product/service was involved.
- What was done.
- Any challenge, decision or constraint worth explaining.
- Evidence: photographs, measurements, timings or notes.
- Outcome that can be supported.
- Practical lesson or customer takeaway.
- Links to the relevant service and location pages.
The page should answer a future customer's questions, not merely prove that the business was busy that day.
Use local context naturally
Location can be useful when it genuinely matters. It may show that the business works in a particular area, explain travel/logistics, or support a location page with real evidence.
But adding “Ballyclare” or “Antrim” ten times does not turn a routine project into useful local content.
A project completed in Antrim should still be a project page about that real job. It should not become a disguised generic “furniture assembly in Antrim” landing page.
Testimonials: use the customer's words carefully
A genuine customer review can strengthen a project page, but only where the wording and publication basis are clear.
Do not rewrite a customer's sentiment to make it sound stronger. Do not invent a quote. Do not attach a private customer's full name to a project simply because it makes the page look more credible.
If a review is already public, it may be possible to quote a short excerpt with attribution, but editorial policy should still consider privacy and context. If the testimonial was supplied privately, obtain permission for publication.
Review acquisition itself belongs in a separate guide.
Projects support service and location pages
Project pages should sit inside a wider site architecture.
A project should link to the service page that owns the commercial service intent. If meaningful, it can also link to the relevant location page. In the other direction, a service or location page may link to one or two strong projects as proof.
The project does not automatically replace the owner page.
For example:
- service page = “what we offer”;
- location page = “how the service applies in this genuinely served area”;
- project page = “evidence of a specific completed job”.
Real Project worked example: Dunelm Olney nest-of-tables job
McKnight's Flat Pack Assembly provides a useful real example because the underlying project details are documented.
Verified facts supplied for the project include:
- genuine Dunelm Olney Nest of Tables with Storage product;
- Ballyclare location;
- two sets assembled;
- two large boxes;
- each set forms a pair of side tables that nest;
- recorded build time of about two hours;
- five job photographs;
- a genuine five-star customer review describing the assembler as punctual, polite and tidy and saying the furniture was built to a high standard.
That is enough substance to make the project more useful than a generic “another job completed” update.
Why this is a strong project candidate
It contains original photographs, a named product range, a recorded build time, multiple units and a genuine customer review. It can answer practical questions such as what the item looks like assembled, what two sets involve and roughly how substantial the assembly was.
What should not be added:
- a claim that the project improved rankings;
- an invented customer problem;
- an invented difficulty during assembly;
- a claim that the customer chose the business because of Google;
- a fabricated enquiry or revenue result;
- private customer details beyond what is appropriate to publish.
- Ballyclare
- Two sets assembled from two large boxes
- Each set forms a nesting pair
- About two hours recorded build time
- Five job photographs
- Genuine public five-star review
No ranking, traffic, enquiry or revenue outcome is claimed.
Reuse genuine facts without creating pointless duplicate pages
One real project can supply useful material for several channels:
- a detailed website project page;
- a shorter portfolio card;
- a Facebook or Instagram post;
- a Google Business Profile update;
- an example inside an educational article;
- a before/after image set where appropriate.
Reusing the facts is not the same as duplicating the same long page everywhere. Each format should serve its own audience and purpose.
A GBP update may be 100 words and one photograph. A website case study may explain the product, work, evidence and lesson in depth. A social post may focus on the visual result. The source facts remain the same.
A project publishing checklist
Before creating a standalone project URL, ask:
- Is the project real and documented?
- Do we have useful original evidence?
- Does the page teach or prove something beyond “job completed”?
- Is the customer/property privacy protected?
- Are testimonial rights/public status clear?
- Does the project add new value rather than repeat an existing page?
- Can it link naturally to the relevant service/location owner?
- Would the page still be useful if the town name were removed from the title?
If several answers are no, keep the project as a smaller portfolio item instead.
Next step
Choose one completed job that clearly passes the qualification test. Gather the photographs, exact product/service details, timings, questions and permissions first. Write the page from that evidence instead of filling a template with generic local SEO copy.